Share via

Migration of Permissions, Delegates, Rooms, Resources, and Tasks from Google Workspace to Exchange Online

This guide is for migration admins who are copying content from Google Workspace Gmail to Microsoft 365 Exchange Online. It explains how to migrate permissions, delegates, rooms, resources, and tasks through cmdlets. The solution is only available for Google's Gmail mailboxes. Currently, there are no plans to migrate similar features from other email/IMAP providers.

Introduction

The Exchange Online migration team is building 1P solutions to automatically migrate permissions, delegates, rooms, resources, and tasks from Google Workspace (GWS). This feature maps the existing data and settings from the source mailboxes in Google to corresponding entities in the Exchange Online mailbox.

Important

The article references migrations of smaller batches or even single-item migration. Admins can also migrate in one large single batch using the information in this article.

Rooms and Resources

Prerequisites for rooms and resources

GWS doesn't expose any API to connect the resource mailbox directly. Exchange Online Migration (or MRS, Mailbox Relocation Services) connects to the users specified in the Gmail endpoint and treats the resource calendar as a shared calendar. This work requires the users specified in the Gmail endpoint to have access permission to the resource calendar. Usually, all users within the tenant should have read permission by default.

For the auto-provisioning option, Migration Service (Exchange Online Migration's batching service) reads the resource information from the Admin portal. This work requires the tenant admin to do the following for the service account used, in addition to the existing prerequisites required for the existing automated GWS mail migration for Mail, Calendar, and contacts:

  1. Enable the Admin SDK API from API Console Portal: https://console.developers.google.com/
  2. Add the new scope "https://www.googleapis.com/auth/admin.directory.resource.calendar.readonly" to Domain-wide Delegation from Admin Console: https://admin.google.com/ac/owl/domainwidedelegation

Onboarding steps for rooms and resources

There are two options for onboarding Google resources/rooms:

Migration Service does the provisioning automatically for the rooms and resources mailboxes. There are two options for the csv schema.

Csv schema 1
  • ResourceId: The resource ID of the Google resource, which can be found in the Google Admin Console: https://admin.google.com/ac/calendarresources/resources.
  • EmailAddress: Optional, the email address of the EXO resource mailbox. The Migration Service auto-generates an email address if this information isn't provided. We're using New-Mailbox -Name "resource name" to create a mailbox, which auto-generates an email address for the mailbox.

The tenant admin can download a resource list from the Google Admin Console: https://admin.google.com/ac/calendarresources/resources. The downloaded list contains many fields that aren't needed, so the tenant admin needs to modify the list to just keep the Resource ID and remove the space between the two words, it should be ResourceId after the removal.

Csv schema 2
  • Username: The email address of the Google resource, which can be found in Google Admin Console: https://admin.google.com/ac/calendarresources/resources.
  • EmailAddress: Optional, the email address of the EXO resource mailbox. The Migration Service auto-generates an email address if this information isn't provided. We're using New-Mailbox -Name "resource name" to create a mailbox, which auto-generates an email address for the mailbox.
The PowerShell command to create the migration batch

New-MigrationBatch -SourceEndpoint MigGmailEndpoint -Name resourceOnboarding -CSVData $([System.IO.File]::ReadAllBytes("C:\ gmail_rooms_resources.csv")) -GoogleResource

Differences with standard Gmail onboarding
  1. There's one new parameter that needs to be specified: -GoogleResource. a. GoogleResource indicates that we're migrating only rooms and resources. Regular users won't be migrated; if a regular user email is added to the .csv, the migration for the particular user fails.
  2. This job doesn't have switch over because Google doesn't support forwarding email address for resources, so: a. The sub-domain in't needed. b. The forwarding email address isn't needed. c. The parameter TargetDeliveryDomain isn't needed.

Option 2

The tenant admin provisions the resource mailboxes by themselves. MRS will copy the data within the resources.

Csv schema 3

The admin is required to create a file (for example gmail_rooms_resources.csv) with two fields:

  1. Username: The email address of Google resource, which can be found in Google Admin Console: https://admin.google.com/ac/calendarresources/resources.
  2. EmailAddress: The email address of Exchange Online resource mailbox.

An example of the csv file:

Username,EmailAddress c_1887rgsar65nig0clnmdl856s87j2@resource.calendar.google.com, conf96@mrs.com

PowerShell command to create the migration batch

New-MigrationBatch -SourceEndpoint MigGmailEndpoint -Name resourceOnboarding -CSVData $([System.IO.File]::ReadAllBytes("C:\ gmail_rooms_resources.csv ")) -GoogleResource -SkipProvisioning

The differences with Gmail onboarding
  1. There are two new parameters that need to be specified: -GoogleResource -SkipProvisioning. a. GoogleResource indicates that we're only migrating rooms and resources calendar data. Regular users won't be migrated; if a regular user email is added to the .csv, the migration for the particular user fails. b. SkipProvisioning, as the name suggests, indicates that there won't be any auto provisioning.
  2. This job doesn't have switch over because Google doesn't support forwarding email address for resources, so: a. The sub-domain isn't needed. b. The forwarding email address isn't needed. c. The parameter TargetDeliveryDomain isn't needed.

Rooms and resource properties that are currently supported during provisioning process

Google resources will be mapped to EXO resource mailboxes. Google buildings will be mapped to EXO DistributionGroups.

Google resource property EXO resource mailbox property
Name Name
Category ResourceType
CONFERENCE_ROOM Room
Others Equipment
Capacity Capacity
Name Display Name
Floor Section Floor Label
Floor Floor
Building ID BuildingID
Building Name Building
Building RegionCode CountryOrRegion
Building AdministrationArea State
Building Locality City
Building Address Street
Building PostalCode PostalCode
Building Coordinates GeoCoordinates

Note

Resource migration is a new feature and was not supported in the existing Gmail migration.

Rooms and resources lifeCycle

We recommend starting resource onboarding before regular (Mail, Calendar, Contact) onboarding, and completing resource onboarding after all the mailboxes in the tenant are migrated to EXO. This onboarding order provides a better user experience for the customer.

Rooms and resources limitations

The coexistence scenario isn't supported because Google doesn't support forwarding email address for resource mailboxes. MRS only supports syncing data from Google to EXO; it doesn't support syncing data from EXO back to Google.

Permissions and Delegates

Note

As of 2024-06-13, the option to migrate permissions and delegates for calendars is turned off worldwide. You can still migrate permissions and delgates for mailboxes.

Prerequisites for permissions and delegates

Assign a license to users with permissions and delegates before onboarding, so MRS can find the mailboxes during migration. The users with permissions and delegates and owner mailboxes can migrate together, but you need to ensure that all users (owners and users with permissions and delegates) are assigned a license so that MRS can find the mailbox and set permissions to them. Otherwise, MRS will mark them as bad items.

Note

The user should be provisioned with a mailbox and license. A mailbox without a license will be converted to a mail user, which isn't supported.

Onboarding steps for permissions and delegates

Enable or Disable the feature for permissions and delegates

Mailbox delegates, send as, and calendar permission are supported while onboarding a Gmail mailbox. They're enabled by default, and tenant admins can specify -SkipDelegates to skip them while creating migration batches.

Once a new migration batch is started, the -SkipDelegates option can't be changed or added later using Set -MigrationBatch cmdlets. If the tenant admin wants to change course and change the options, they'll need to remove the migration batch and create a new one. This can't be edited for a batch in progress.

Permission sync behavior

Because applying permissions needs time to take effect, and permission changes don't happen often, MRS copies permissions in both incremental sync and final sync, giving AD enough time to sync the permissions. Because Google doesn't support ICS for permissions, MRS saves the source permissions to persisted sync state after each sync, enabling MRS to detect permission changes in the next round of sync.

For existing permissions on the EXO mailbox, MRS will merge the permissions:

  1. If the Gmail mailbox has applied some permissions for the same user, MRS will override the permissions during onboarding.
  2. If the Gmail mailbox doesn't apply any permissions for the same user, it won't be impacted during onboarding, meaning MRS won't remove it from EXO.

Permission mapping

Google EXO
Delegates Full access and Send on behalf to
Send as Send as
See only free/busy Can view when I'm busy
See all event details Can view all details
Manage changes to events Edit
Manage changes and manage sharing Edit

Note

MRS will only migrate the permissions that have an accepted status in Google. All other statuses mean it's not applied successfully in Google. We rely on Google APIs to learn the delegate status.

Migration lifecycle for permissions and delegates

We recommend that users with permissions and delegates be migrated first among the population. The automated migration of permissions and delegates for mail and calendars is enabled by default during regular migrations from GWS Mails, Calendars, and Contacts. The tenant admin can specify -SkipDelegates to skip them while creating migration batches.

Permissions and delegates limitations

  1. If a mailbox or group doesn't exist in the target tenant, MRS won't migrate the permissions, and MRS will report a bad item.
  2. MRS doesn't support copying permissions partially for a single object. An object means a single folder, mailbox security descriptor, or user security descriptor. – Example 1: (Mailbox permission - not impacting SendAs or any of the calendar permissions, only impacting Delegate). For example, your Google account has two delegates: user1@google.com and user2@google.com. If user2 doesn't exist in the target tenant, all the delegates (including user1) won't be copied, but SendAs and calendar permissions aren't impacted. This situation is only for Mailbox. – Example 2: (for Calendar permissions - Mailbox permissions aren't impacted, impacts all calendar permissions for that specific calendar of that particular user). Google calendar has two permissions: users user1@google.com and user2@google.com. If user2 doesn't exist in the target tenant, all the permissions of this calendar won't be copied as well, but mailbox and the permissions of other calendars (of the same user) aren't impacted. This situation is only for Calendar.

Note

After the tenant admin fixes the issue, a new round of incremental sync can copy the permissions to the target successfully.

Tasks

Tasks prerequisites

Migration Service needs to read the resource information from the Admin portal. This work requires the customer to enable the new API:

  1. Enable Google Tasks API from API Console Portal: https://console.developers.google.com/.
  2. Add the new scope "https://www.googleapis.com/auth/tasks.readonly" to Domain-wide Delegation from Admin Console: https://admin.google.com/ac/owl/domainwidedelegation.

Onboarding steps for tasks

Enable or disable the feature for tasks

Once a new migration batch is started, the -MigrateTasks option can't be changed or added later using Set -MigrationBatch cmdlets. If the tenant admin wants to change course and change the options, they need to remove the migration batch and create a new one. This can't be edited for a batch in progress.

Customers need to specify -MigrateTasks when using New-MigrationBatch.

Example: New-MigrationBatch -SourceEndpoint MigGmailEndpoint1 -Name TaskMigrationTest -TimeZone "Pacific Standard Time" -NotificationEmails zhowa@contoso.com -CSVData $([System.IO.File]::ReadAllBytes("D:\gmail.csv")) -autostart -TargetDeliveryDomain "mrs.com" -MigrateTasks -AutoComplete

Task migration process

This step happens before the migration batch is completed. Task folders are created, and the tasks are migrated only once. Incremental Sync isn't supported for an already-migrated task.

Google entities Exchange entities
Task list Task folder
Parent task Task
Child task Task
Google task list properties Exchange task folder properties
ID ID
Title Name
Google task properties Exchange task properties
ID ID
Title Subject
Notes Body
Status Status
DueDate Due
CompletedDate Completed

Tasks lifecycle

The automated migration of Tasks is recommended to be done along with the migration of mail, calendar, and contacts, with the -MigrateTasks parameter.

Tasks limitations

  1. No instances of repeated tasks will be migrated because the existing Google API doesn't provide that information in the API.
  2. Task attachments won't be migrated because Google can't provide that information in the API.
  3. Exchange doesn't support task hierarchy. As a result, tasks hierarchy isn't preserved when migrating from GWS to Exchange.
  4. Deleted or hidden tasks won't be migrated.
  5. Google tasks can be parent tasks or child tasks. Exchange tasks don't support child tasks very well. The tasks hierarchy and parent-child relationship isn't preserved during migration.