How to Perform an Automated Google Workspace migration to Microsoft 365 – Part I

Posted on January 8, 2025 by jovathis

Migrating from Google Workspace to Microsoft 365 can be a daunting task, especially when dealing with mailboxes over 100 GB. This guide provides an in-depth look at the challenges and solutions for a successful migration, catering to both normal and large mailboxes.

Assessment and Planning

Before initiating the migration, it’s crucial to carry out a thorough assessment of your current Google Workspace environment. Identify the number of users, mailbox sizes, and any potential issues that might arise. Planning should include:

Identifying key stakeholders
Defining the migration timeline
Determining the migration method
Allocating resources and roles

You can migrate the following functionalities from Google Workspace to Microsoft 365 or Office 365:

Mail & Rules
Calendar
Contacts

You can migrate batches of users from Google Workspace to Microsoft 365 or Office 365, allowing a migration project to be done in stages. This migration requires that you provision all of your users who will be migrated as mail-enabled users outside of the migration process. You must specify a list of users to migrate for each batch.

All procedures in this article assume that your Microsoft 365 or Office 365 domain is verified and that your TXT records have been set up. For more information, see Set up your domain (host-specific instructions).

Select your method of migration

You can migrate from Google Workspace using any of the following methods:

Automated – through the Exchange admin center
Manual – through the Exchange admin center
PowerShell

Migration limitations

Important
Microsoft’s data migration tool is currently unaware of tools enforcing messaging records management (MRM) or archival policies. Because of this, any messages that are deleted or moved to archive by these policies will result in the migration process flagging these items as “missing”. The result is perceived data loss rather than actual data loss, which makes it much harder to identify actual data loss during any content verification checks. Therefore, Microsoft strongly recommends disabling all MRM and archival policies before attempting any data migration to mailboxes.

Note
The largest single email message that can be migrated is based on the transport configuration for your configuration. The default limit is 35 MB. To increase this limit, see Office 365 now supports larger email messages.

Throughput limitations for contacts and calendars completely depend on the quota restrictions for your tenant’s service account on the Google Workspace side.

Other migration limitations are described in the following table:

Data type	Limitations
Mail	Vacation settings, Automatic reply settings
Meeting rooms	Room bookings won’t be migrated
Calendar	Shared calendars and event colors won’t be migrated
Contacts	A maximum of three email addresses per contact are migrated over
Contacts	Gmail tags, contact URLs, and custom tags won’t be migrated

Google Workspace migration prerequisites in Exchange Online

The following procedures must be performed (in the order mentioned) before you start the process of Google Workspace migration:

Create a subdomain for mail routing to Microsoft 365 or Office 365
Create a subdomain for mail routing to your Google Workspace domain
Provision users in Microsoft 365 or Office 365

Create a subdomain for mail routing to Microsoft 365

Go to the Google Workspace Admin page and sign in as a Google Workspace administrator for your tenant.
Select Add a domain.

Note
The option Add a domain won’t be available if using the legacy free edition of G Suite.

Enter the domain that you’ll use for routing mails to Microsoft 365 or Office 365, select User alias domain, and then select ADD DOMAIN & START VERIFICATION. A subdomain of your primary domain is recommended (for example, “m365mail.domain.com”, when “domain.com” is your primary domain) so that it will be automatically verified. If another domain (such as “domain.onmicrosoft.com”) is set, Google will send emails to each individual address with a link to verify the permission to route mail. Migration won’t complete until the verification is completed.

Keep track of the name of the domain you enter because you’ll need it for the subsequent steps, and for using it as the Target Delivery Domain in the process of Creating a migration batch in Microsoft 365 or Office 365.

Note
If you see an error GmailForwardingAddressRequiresVerificationException has occurred during the batch, skip this step of creating a subdomain for forwarding emails from the gmail side.

Follow any subsequent steps that are then required to verify your domain till the status is shown as Active. If you chose a subdomain of your primary domain (created in step 3), your new domain may have been verified automatically.

Sign in to your DNS provider and update your DNS records so that you have an MX record at the domain you created (in step 3), pointing to Microsoft 365 or Office 365. Ensure that this domain (created in step 3) is an accepted domain in Microsoft 365 or Office 365. Follow the instructions in Add a domain to Microsoft 365 to add the Microsoft 365 or Office 365 routing domain (“m365mail.domain.com”) to your organization and to configure DNS to route mail to Microsoft 365 or Office 365.

Note
The migration process won’t be able to complete if an unverified routing domain is used. Choosing the built-in “tenantname.onmicrosoft.com” domain for routing mail to Office 365 instead of a subdomain of the primary Google Workspace domain occasionally causes issues that Microsoft is not able to assist with, besides causing Microsoft to recommend that the user manually verify the forwarding address or contact Google support.

Create a subdomain for mail routing to your Google Workspace domain

Go to the Google Workspace Admin page and sign in as a Google Workspace administrator for your tenant.
Select Add a domain.
Enter the domain that you’ll use for routing mails to Google Workspace, select User alias domain, and then select ADD DOMAIN & START VERIFICATION. A subdomain of your primary domain is recommended (for example, “gsuite.domain.com”, when “domain.com” is your primary domain) so that it will be automatically verified.

Follow any subsequent steps that are then required to verify your domain till your domain’s status is shown as Active. If you chose a subdomain of your primary domain (created in step 3), your new domain may have been verified automatically.

Follow Google’s instructions to Set up MX records for Google Workspace Gmail for this domain.

Note
It may take up to 24 hours for Google to propagate this setting to all the users in your organization.

Important
If you are using non-default Transport settings in your Microsoft 365 or Office 365 organization, you should check whether the mail flow will work from Office 365 to Google Workspace. Ensure that either your default Remote Domain (“*”) has Automatic Forwarding enabled, or that there is a new Remote Domain for your Google Workspace routing domain (for example, “gsuite.domain.com“) that has Automatic Forwarding enabled.

Check Google Cloud platform permissions

An automated scenario requires the Google Migration administrator to be able to perform the following steps in the Google admin console:

Create a Google Workspace project.
Create a Google Workspace service account in the project.
Create a service key.
Enable all APIs – Gmail, Calendar, and Contacts.

The Google Migration administrator needs the following permissions to complete these steps:

resourcemanager.projects.create
iam.ServiceAccounts.create

The most secure way to achieve completion of these four steps is to assign the following roles to the Google Migration administrator:

Projector Creator
Service Accounts Creator

Here’s how you do it:

Navigate to https://console.developers.google.com.
Expand the hamburger menu in the upper right-hand corner.

Select IAM & Admin.
Select Manage Resources.

Select the appropriate resource and in the right-hand pane under the Permissions tab, select Add Principal.

Enter your Google Migration administrator credentials, enter Project Creator in the filter, and select Project Creator.
Select Add Another Role, enter Create Service Accounts in the filter, and select Create Service Accounts.
Select Save.

Note
It might take up to 15 minutes to propagate role assignment changes across the globe.

Provision users in Microsoft 365. Once your Google Workspace environment has been properly configured, you can complete your migration in the Exchange admin center or through the Exchange Online PowerShell.
Before proceeding with either method, ensure that Mail Users have been provisioned for every user in the organization who will be migrated (either now or eventually). If any users aren’t provisioned, provision them using the instructions in Manage mail users.

Very Important Note
Microsoft recommend that the Default MRM Policy and Archive policies be disabled for these users until their migration has been completed. When such features remain enabled during migration, there is a chance that some messages will end up being considered “missing” during the content verification process.

Start an automated Google Workspace migration batch in EAC

In the Exchange Admin center, go to Migration, and then select Add migration batch.

The Add migration batch page appears.

Configure the following settings:

Give migration batch a unique name: Enter a unique name.
Select the mailbox migration path: Verify that Migration to Exchange Online is selected.

When you’re finished, click Next.

On the Select the migration type page, select Google Workspace (Gmail) migration as migration type, and click Next.

The Prerequisites for Google Workspace migration page appears.

Verify that the Automate the configuration of your Google Workspace for migration section is expanded, and then select Start in that section to automate the four required prerequisite steps.

In the Google sign-in page that appears, sign in to your Google account to validate your APIs.

Once the APIs are successfully validated, the following things happen:

A JSON file (projectid-*.json) is downloaded to your local system.
The link to add the ClientID and the Scope is provided. The ClientID and Scope are also listed for your reference.

Select the API access link. You’ll be redirected to Google Admin API Controls page.
Select Add new. Copy the ClientID and Scope from the EAC, paste it here, and then select Authorize.
Once the four prerequisites-related steps are completed, select Next. The Set a migration endpoint page appears.
Select one of the following options:
- Select the migration endpoint: Select an existing migration endpoint from the drop-down list.
- Create a new migration endpoint: Select this option if you’re a first-time user.

Note
To migrate Gmail mailboxes successfully, Microsoft 365 or Office 365 needs to connect and communicate with Gmail. To do this connection-communication, Microsoft 365 or Office 365 uses a migration endpoint. Migration endpoint is a technical term that describes the settings that are used to create the connection so you can migrate the mailboxes.

If you’ve selected Create a new migration endpoint, do the following steps:

On the General Information page, configure the following settings:
- Migration Endpoint Name: Enter a value.
- Maximum concurrent migrations: Leave the default value 20 or change the value as required.
- Maximum concurrent incremental syncs: Leave the default value 10 or change the value as required.
  When you’re finished, select Next.
On the Gmail migration configuration page, configure the following settings:
- Email address: Enter the email address that you use to sign in to the Google Workspace.
- JSON key: Select Import JSON. In the dialog box that appears, find and select the downloaded JSON file, and then select Open.
  Once the endpoint is successfully created, it will be listed in the Select migration endpoint drop-down list.
- Select the endpoint from the drop-down list, and select Next. The Add user mailboxes page appears.

Select Import CSV file and navigate to the folder where you’ve saved the CSV file.

If you haven’t already saved or created the CSV file, create a CSV file containing the set of names of the users you want to migrate. You’ll need its filename below. The allowed headers are:

EmailAddress (required): Contains the primary email address for an existing Microsoft 365 or Office 365 mailbox.
Username (optional). Contains the Gmail primary email address, if it differs from EmailAddress.

CSV Format

EmailAddress
will@domain.com
user123@domain.com

When you’re finished, click Next. The Move configuration page appears.

From the Target delivery domain drop-down list, select the target delivery domain (the subdomain) that was created as part of fulfilling the Google Workspace migration prerequisites in Exchange Online, and click Next.

Note
The target delivery domain (the subdomain) you select in this step can be either an existing one or the one that you’ve created in Google Workspace migration prerequisites in Exchange Online (eg. M365mail.domain.com).

If you don’t see the target delivery domain that you want to select in the Target delivery domain drop-down list, you can manually enter the name of the target delivery domain in the text box.

The text box in which you manually enter the name of the target delivery domain is Target delivery domain. That is, the text box is effectively the Target delivery domain drop-down list, which is taking the role of a text box when you manually enter text into it.

Filtering options have been introduced for the migration of Google Workspace to Microsoft 365 or Office 365. For more information on these filtering options.

On the Schedule batch migration page, verify all the details, click Save, and then click Done.

Once the batch status changes from Syncing to Synced, you need to complete the batch.

In Part II we will describe how to handle the large mailboxes (>100 GB) and the challenges we will face.
Stay tuned 😊

Microsoft Introducing cloud.microsoft URL

Posted on October 11, 2024 by jovathis

As Microsoft cloud services have grown over the years, the domain space they live on has grown as well – into the hundreds. Over time, this fragmentation has created increasing challenges for end user navigation, administrative simplicity, and the development of cross-app experiences. Microsoft’s announcement, “cloud.microsoft is the new unified domain for Microsoft 365 apps and services.” It promises greater security and unified experience.

Why cloud.microsoft?

‘Dot brand’ top-level domains like .microsoft are an established method for enhancing the security, trustworthiness, and integrity of an organization’s web offerings. Similar to how the US government has exclusive rights to the .gov top-level domain (TLD), Microsoft has exclusive rights to the .microsoft TLD. Exclusive ownership enables enhanced security protocols and governance controls, and the value of security investments done at the top-level domain seamlessly accrue to the apps. And all experiences hosted on the .microsoft domain can be assumed to be legitimate and authentic: anyone attempting domain spoofing would have to go through Microsoft itself, as we are both the registry operator and sole registrant for this exclusive, trusted namespace. A common term before the “dot” is also necessary in order to realize the full benefits of a unified domain. “Cloud” was selected as a durable, extensible, neutral term with a meaningful relationship to the wide range of services that will come under its umbrella, starting with Microsoft 365.

Additional information’s you can find here.!

Microsoft 365: Admins can no longer receive user passwords in email as of August 30, 2024

Posted on July 30, 2024 by jovathis

Microsoft will be retiring the Send password in email feature from Microsoft 365 admin center starting August 30, 2024. Instead, Microsoft recommend using the new Print option in the Microsoft admin center to save the user account details and share them in a secure manner with your users.

Admins will no longer be able to receive usernames and passwords in email after this change is implemented. This change will happen automatically by the specified date. No admin action is required.

REFERENCES

Enhance Excel Data with Microsoft Copilot | Tips & Tutorial

Posted on June 26, 2024 by jovathis

Microsoft Copilot in Excel helps you do more with your data in Excel tables by generating formula column suggestions, showing insights in charts and PivotTables, and highlighting interesting portions of data.

Open Excel in Microsoft 365.

2. Open a workbook stored on OneDrive or SharePoint.
Important:
Your data needs to be formatted in specific ways (see Format data for Copilot in Excel), and you’ll need to select a cell within your table or data range before using Copilot.

4. Select Copilot on the ribbon to open the chat pane.
Tip: If you can’t select the Copilot button in the ribbon, try saving the file to the cloud first.
5. Enter your prompts and start working with Copilot.

Learn more about creating effective prompts at Copilot Lab.

Multi-tenant organization capabilities now available in Microsoft 365

Posted on April 30, 2024 by jovathis

On the 25th of April, Microsoft announced a robust set of multi-tenant organization (MTO) capabilities within Microsoft 365, now generally available to enhance any organization’s collaboration, communication, and administration across multiple tenants. These capabilities span Microsoft 365 People Search, Microsoft Teams, Viva Engage and Microsoft Defender XDR, which can be enabled via the Microsoft 365 admin center or Microsoft Entra admin center.

This segmentation can cause frustration when users need to communicate and collaborate across tenant boundaries, whilst IT admins need to perform the same set of administrative tasks per tenant to maintain their organization.

A diagram showing multiple tenants within a single organization.

The capabilities we discuss below help multi-tenant organizations address these complexities, while staying compliant and secure:  

Find people across organizations easily: Search for and communicate with colleagues in a unified manner with improved people search. Every search now returns a single, accurate result, simplifying how you connect with the right colleague.
Streamlined workforce collaboration: Engage in calls, chats, and meetings across tenants without the barriers of meeting lobbies. Enjoy immediate access to meeting content and collaborative tools in real time.
Unlock new ways for employees and leaders to connect: We’ve broadened the capabilities in Viva Engage, facilitating cross-tenant announcements and enabling community interaction and campaign participation that extend beyond tenant boundaries.  
Manage incidents across tenants: Microsoft Defender XDR provides a single, unified view of all tenants your organization manages, allowing for swift incident investigation and advanced threat hunting without the need to switch between tenant views.  
Simplify multi-tenant management: The newly defined multi-tenant organization boundary in Microsoft Entra ID P1 simplifies the enablement, configuration and management of the capabilities above. Whether through Microsoft Graph APIs or the Microsoft 365 Admin Center, setting up is intuitive and straightforward.

Find people across organizations easily with People Search

The multi-tenant organization (MTO) People Search is a collaboration feature that enables search and discovery of people across multiple tenants. A tenant admin can enable cross-tenant synchronization that allows users to be synced to another tenant and be discoverable in its global address list. Once enabled, users can search and discover synced user profiles from the other tenant and view their corresponding people cards.

An image showing a synchronized user profile from another tenant in Microsoft 365

Streamline workforce collaboration with Microsoft Teams

Once administrators form a multi-tenant organization in the Entra ID platform organizations with the new Teams desktop client will automatically receive the Teams MTO features with no additional configuration.
Users can now join a meeting, chat, call, or collaborate in a channel hosted by another tenant, and simultaneously compose chat messages in their own tenant. Users can receive cross-tenant notifications for all accounts and tenants added to the Teams client, no matter which one is currently in focus.
People’s search is also improved. Searches for coworkers in a multi-tenant organization could often return multiple results for the same person. With the new MTO capabilities in the new Teams client, searching for a coworker in an MTO will return a single result, helping you to identify the correct colleague and keep your conversations in one place.

The new Teams desktop client showing improved people search capability on the right hand side
Users that join a meeting in another tenant can now bypass the meeting lobby, have access to all in-meeting content and resources and can collaborate in real time.

Manage incidents across tenants with Microsoft Defender XDR

Security operations teams that work with multiple tenants need a reliable and comprehensive security solution that can keep up with modern threats and provide unified and connected experience to enhance their security operations. Microsoft Defender XDR now delivers unified investigation and response experience for multi-tenant organizations alongside native protection across endpoints, identities, email, collaboration tools, cloud apps, and data.

With multi-tenant management in Microsoft Defender XDR, security operations teams can quickly investigate incidents and perform advanced hunting across data from multiple tenants, removing the need for administrators to log in and out of each individual tenant.

Enable Microsoft 365 multi-tenant capabilities with Microsoft Entra ID

Multi-tenant organization platform capabilities are now rolling out to standard production tenants in Microsoft 365. To deliver the above capabilities, administrators can enable multi-tenant capabilities in the Microsoft 365 admin center and configure which users in the organization can take advantage of multi-tenant capabilities using either Microsoft 365 admin center or Microsoft Entra admin center.

This approach allows you to define a boundary around the Entra ID tenants that your organization owns, facilitated by an invite-and-accept flow between tenant administrators. Learn more about the process in the Microsoft 365 admin center here and using Microsoft Graph API’s here. We recommend the use of the Microsoft 365 admin center to simplify the setup experience and to view your newly created MTO:

Snapshot of a multitenant organization collaboration with three tenants.

Following the formation of the multi-tenant organization, Microsoft offers two methods to provision employees into neighboring multi-tenant organization tenants at scale.

For a simplified experience, stay in the Microsoft 365 admin center to sync users into multiple tenants in your multi-tenant organization. Microsoft recommend this method for smaller multi-tenant organizations who plan on all employees receiving access to all multi-tenant organization tenants.
For a customizable sync experience, head over to Entra ID cross-tenant synchronization. Cross-tenant synchronization is highly configurable and allows the provisioning of any multi-hub multi-spoke identity landscape. We recommend this method for enterprise organizations of complex identity landscapes. Either method works. Choose the one that works best for your specific organization!

Stay Tune…..

Overview of Microsoft 365 Multi-Tenant Organizations (Preview)

Posted on January 12, 2024 by jovathis

Microsoft has multi-tenant organizations, a new Entra ID solution that’s available in Preview.

The multitenant organization capability is designed for organizations that own multiple Microsoft Entra tenants and want to streamline intra-organization cross-tenant collaboration in Microsoft 365. It’s built on the premise of reciprocal provisioning of B2B member users across multitenant organization tenants.

Collaboration in Microsoft 365 is built on the premise of reciprocal provisioning of B2B identities across multitenant organization tenants.

Members Not Guests

When Entra ID synchronizes accounts from a source tenant to a target tenant, it creates the entries in the target tenant as member accounts, not guest accounts. If you examine the properties of a synchronized account, you can see that the user principal name looks like a guest account but the user type is the same as a regular user account:

Side-by-side multitasking and cross-tenant notifications

With the new Teams client, users can now work across multiple tenants and accounts in side-by-side windows. They can join a meeting or collaborate in a channel hosted in another tenant, and simultaneously compose chat messages in their own tenant. Users can receive cross-tenant notifications for all accounts and tenants added to the Teams client, no matter which one is currently in focus.

Limitations for multitenant organizations in Microsoft 365 preview

The following are limitations of the multitenant organizations in Microsoft 365 preview:

A maximum of five tenants in the multitenant organization is supported.
A maximum of 100,000 users per tenant is supported.
Teams on the web, Microsoft Teams Rooms (MTR), and VDI/AVD aren’t supported.
The ability to grant or revoke permission to receive notifications from other tenants and to switch between tenants isn’t supported on mobile.
People in your organization links may not work for users from another tenant if their account had originally been a guest and they had previously accessed SharePoint resources.
It might take up to seven days for a user to appear in search once they’ve been synchronized. Contact Microsoft support if users aren’t searchable after seven days.
Support for a guest UserType of member in Power BI is currently in preview. For more information, see Distribute Power BI content to external guest users with Microsoft Entra B2B.

If you want to add more than five tenants or 100,000 users per tenant, contact Microsoft support.

Cross-tenant synchronization in Microsoft Teams:

Cross-tenant synchronization is a one-way process. This means that users from the source tenant are synchronized to the target tenant, but not the other way around.
Synchronized users have their own account in the target tenant. This means that they have their own profile, mailbox, and Teams chat history.
Synchronized users can access Teams in the target tenant. They can chat with other users, join teams, and participate in meetings.
Synchronized users cannot access other Microsoft 365 services in the target tenant. This is because they are not considered to be full members of the target tenant.

The basic issue here is that the original cross-tenant synchronization mechanism wasn’t tailored to support Microsoft 365 apps. The MTO (Multi-Tenant Organization) is explicitly engineered to support Microsoft 365, so it looks (from initial tests) that the use objects synchronized to another tenant a) appear in the GAL and b) are routable because their SMTP mail address is valid.

In the next post we will go deeper on how to configure MTO step by step. Stay tune for more goodies …