Configure Teams to Co-exist with Google Workspace

Configure Teams to Co-exist with Google Workspace

5/5 - (21 votes)

With the rise of remote work over the past several weeks (now turned months and years), I’ve engaged with many customers who want to use Microsoft Teams to as part of their work-from-home tool set.  Many of my customers have investments in both Microsoft Office 365 as well as Google G Suite Workspace or Google Apps (frequently with other third-party IdP, metadirectory, and federation services thrown in the mix), so it’s not always just as easy as “flipping a switch.”

Here’s the process that my fantastic coworker, Angel Aviles, and I worked out to help our customers get the most out of both platforms.


First, a little background on what it takes for a successful Microsoft Teams deployment.

  • You must have an identity (duh).  For most customers that are running both G Suite Google Workspace and Office 365, they’ll have one or more identity provisioning engines.  The most common identity provisioning scenario is using Azure Active Directory Connect to synchronize identity to Office 365 and Google Cloud Directory Sync (formerly Google Apps Directory Sync) to synchronize identity to G Suite Google Workspace, though you can also use Azure Active Directory to provision G Suite Google Workspace users automatically (which is what I recommend for organizations that need to maintain both systems).
  • You must have an Exchange Online Mailbox  license enabled in order to see the calendaring option.

    If you don’t have the Calendar option available, then you definitely don’t have an Exchange Online license assigned.  The calendar option requires EWS-based access to a user’s mailbox (either in Exchange Online or through Exchange hybrid to an on-premises mailbox).  This is important, as it goes to one of our troubleshooting steps later.  There are other considerations when trying to get Teams calendaring to work with Exchange Hybrid and eDiscovery–we’ll save those for another post.
  • 1:1 Chat-based sharing requires a SharePoint Online license with OneDrive for Business provisioned.  Behind the scenes, when you share a file via IM or peer-to-peer chat, the file is silently uploaded to OneDrive for Business and each recipient is granted sharing permission to it.  Without a SharePoint Online license and OneDrive for Business provisioned, users will be unable to upload files.

Many organizations that use both service platforms choose to limit or restrict certain features in one platform–for example, enabling Google Drive but disabling OneDrive or enabling Exchange Online mail but disabling Gmail–to ensure that everyone uses the same tools.  In the case of converged applications like Teams, however, we need to have things enabled at some level and use both technology and user education to help workers be efficient.

We do have some additional information at, but this largely doesn’t address concerns when you have the same verified domain in each tenant, or actual calendar routing or message delivery. That’s where this post comes in. 🙂

Finally, please note that while some of this is based on our docs article and relies on configuring normal things like transport rules or using the Teams plug-in for Outlook, the steps outlined here are not officially supported by Microsoft. It’s best effort by your own IT staff.

There’s the background and disclaimers–now, let’s move on to some common issues!

New Feature: Microsoft Teams Add-On for G Suite Google Workspace

It didn’t generate a whole lot of noise at the introduction, but we did release an add-in to allow direct Microsoft Teams meeting scheduling from G Suite Google Workspace.  It helps alleviate some of the free-busy issues users encounter when trying to schedule Teams meetings from the Teams UI.

The idea is that G Suite Google Workspace users can individually deploy this add-in to their G Suite Google Workspace calendars. After the user configures it and logs into their individual Office 365 account, they’ll be able to click a button and add the Teams meeting info into the meeting they schedule from the G Suite Google Workspace calendar (pro-tip: it also works with consumer G Mail).

This configuration has two parts. First, there’s an administrator requirement to enable the add-on in the Office 365 / Azure tenant.  Then, once that’s configured, users can add it individually to their G Suite Google Workspace mailboxes.


To perform the admin configuration, you’ll need to be a global admin and navigate to the Azure portal.

  1. Open the Azure portal (
  2. Navigate to Enterprise applications | All applications (
  3. Under Application type, select All Applications.
  4. Locate the Microsoft Teams meeting add-on for Google Workspace and select it.  If you got to the end of this sentence and realized you don’t have that application showing up in Enterprise Apps, don’t panic.  We allow this plug-in to work without it showing up.  You will only see this if you create the application ID manually.
  5. Under Manage, select Properties.  Switch the Enabled for users to sign-in? toggle to Yes if it’s not already there and click Save.
  6. Like I said earlier, if the Azure portal in your tenant doesn’t display this application, that’s ok. The Microsoft Teams service is configured to allow the add-on, even if you don’t see it listed in Enterprise Applications.  If you want to create the AppId, you’ll need to connect to Azure AD PowerShell and run this:
    # Create and enable AppID for Microsoft Teams meeting add-on
    $displayName = 'Microsoft Teams meeting add-on for Google Workspace' 
    $appId = '7969c887-ba98-48bb-8832-6c9239929d7c' # Check if a service principal already exists for the app $servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'" 
    if ($servicePrincipal)
         Set-AzureADServicePrincipal -ObjectId $servicePrincipal.ObjectId -AccountEnabled $true
         New-AzureADServicePrincipal -AppId $appId -DisplayName $displayName -AccountEnabled $true

In the future, if you want to disable the Add-on, you can go back to the Enterprise Apps portal (if the AppId exists) and disable it (step 5 above), or you can run this snippet from the Azure AD PowerShell to create-and-disable the AppId..

$displayName = 'Microsoft Teams meeting add-on for Google Workspace' 
$appId = '7969c887-ba98-48bb-8832-6c9239929d7c' # Check if a service principal already exists for the app $servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'" 
$servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"
if ($servicePrincipal)
     Set-AzureADServicePrincipal -ObjectId $servicePrincipal.ObjectId -AccountEnabled $false
     New-AzureADServicePrincipal -AppId $appId -DisplayName $displayName -AccountEnabled $false

After disabling it, users will see this error when attempting to use it:

That’s it for the admin side.


Without further ado, here we go!  Remember, this part is per-userso each user will have to perform these steps.

  1. Log into the G Suite Google Workspace calendar.
  2. On the right-hand side of the page, click the + button to Get Add-ons.
  3. From the Google Workspace Marketplace, locate and select the Microsoft Teams meetings addon.
  4. Click Install.
  5. Click Continue.
  6. Verify that you’re adding it to the correct account.  View the permissions it’s going to require and then click the Allow button to authorize it.
  7. Click Done.
  8. On the right-hand bar, select the Microsoft Teams Add-on.
  9. Select Login.
  10. Click Authorize Access.

  11. Select the Office 365 account that you want the G Suite Google Workspace calendar add-on to use.  The Microsoft Teams add-on will use the meeting information configured for this account (Teams meeting URL and conference bridges, if available) when generating Teams meetings info for your G Suite Google Workspace calendar invitations.
  12. Complete the sign-in process.
  13. Bada-bing, bada-boom! You’re connected!

Next, you can use the calendar add-on to create Teams meetings from G Suite.

  1. From the G Suite Google Workspace calendar, create a meeting.
  2. Click the Add Microsoft Teams Meeting button to populate the invitation with the Teams meeting information from the connected Office 365 account.
  3. Verify that the correct meeting information is shown and click Save.

As the originator, you’ll have the meeting saved in your local G Suite Google Workspae calendar, and recipients will receive a copy of the meeting with the Teams info attached.

Issue 1: Users are unable to share files in chat

Many of my dual-platform customers have Office 365 mainly for the Office ProPlus subscription feature–so, they only need identity synchronized to the cloud and an Office 365 ProPlus license assigned and don’t provision many other services.

Files upload being unavailable in chat is likely due to one of two conditions:

  • permissions on the User Profile Service
  • user has not logged into OneDrive for Business

As previously stated, in order for 1:1 file sharing to work, users will need a SharePoint Online license provisioned and OneDrive for Business sites activated. The reason I draw attention to that activated part is that I’ve had many customers over the years enable SharePoint Online but disable automatic provisioning of OneDrive for Business sites by removing the permission from the User Profile Service.

Next, I’ll show you how to check and verify that it’s all working.

Resolution 1: Enable OneDrive for Business

You’ll need to go to the admin center (, select an active user, and assign a SKU that has SharePoint Online.  You’ll also need to ensure the SharePoint Online service plan is actually selected (for example, many of my customers that are only using Office 365 for Office 365 ProPlus or Planner or other services have specifically disabled this service plan).  What am I talking about?


But A-A-Ron, you say–

My users have licenses assigned but still aren’t able to chat!  Read on, administrator!

Resolution 2: Ensure the permissions for the User Profile Service are correct

Many organizations that run both Office 365 and G Suite Google Workspace limit the services available in either platform.  It gives both the users and administrators “one place” to check.  When you have multiple ways of doing something, it can become challenging to troubleshoot.  For organizations that have access to both Google Drive and OneDrive, it may make sense to prevent users from using one of them. Some organizations have chosen to do this by changing the permissions on the SharePoint User Profile Service, which is responsible for OneDrive for Business (or My Sites, if you’re old like me).

You can check the permissions of the User Profile Service using these steps.

  1. Navigate to the Microsoft 365 admin center (, expand Admin centers, and select SharePoint.
  2. Expand More features and select Open under User profiles.
  3. Select Manage User Permissions.
  4. Ensure Create Personal Site (required for personal storage, newsfeed, and followed content) is enabled and click OK.  If this box is clear, users are unable to provision OneDrive sites.

Now that we’ve got that straightened out, let’s make sure the sites get created …

Resolution 3: Pre-provision OneDrive Sites

A user’s OneDrive for Business site isn’t provisioned until the user logs in the first time.  If users aren’t normally storing their files in OneDrive or using Office 365 as their main productivity platform, they likely have not done this step.  In the case that everything is configured correctly (either it already was or you just fixed it using the steps above), you should ensure that every user has a OneDrive site by pre-provisioning it yourself.  That will remove the need for the user to log in and kick off the self-provisioning.

You can pre-provision sites for OneDrive users with the SharePoint Online Management Shell.  You’ll need to know your tenant name (as in and have an administrative credential.  You’ll also need the Microsoft Online Services Module, which you can install on Windows 10 using Install-Module MSOnline.  You can use a script like the following to instantiate an OneDrive for Business site:

$TenantName = Read-Host "Enter your Office 365 Tenant name ( domain)"
$Credential = Get-Credential -Message "Enter Office 365 Global Admin Credential"
Connect-MsolService -Credential $Credential
$Tenant = "https://"+$tenantname.split(".")[0]+""
Connect-SPOService -Url $Tenant -Credential $Credential
$Users = Get-MsolUser -All | Select UserPrincipalName
Request-SPOPersonalSite -UserEmails $Users

If you are requesting the provisioning of a lot of sites, it may take a few hours.  If sites haven’t provisioned in 24 hours, contact Office 365 support.

Issue 2: Calendar icon isn’t displayed for users

In the current “everyone work from home” climate, online meetings are critical to ensuring tasks things are running on schedule.  Transitioning in-person meetings to remote meetings can be challenging enough already.  Not having the calendar icon available to schedule a meeting makes it even more difficult.

Before we dive into the mechanics of this, I want to be clear: this will not be a 100% solution for everything.  Google does support a cross-platform calendar interoperability, but it is not designed for users that exist in both platforms with the same identity.

I’m going to say this again for the people in the back: it is not designed for users that exist in both platforms with the same identity.

The reason for this is that interop specifically looks in a remote environment for users that don’t exist in your local environment.  If you have a local mailbox and calendar for a user, there’s no reason to cross the interop connection.

What this means:

When a user is in Teams and wants to schedule a meeting with a G Suite Google Workspace user in the same domain, they will only see the invited user’s availability as it appears in the local Exchange Online calendar.  They will not see availability for the invited user in G Suite Google Workspace, so meeting invitations will be sent ‘blind.’  You may want to look at a third-party solution such as SyncGene to keep the Office 365 calendar up-to-date if the G Suite Google Workspace calendar is primary.

Resolution: Provision a mailbox in Office 365

There are a lot of moving parts in this, so be sure you understand them all.  The first step is to ….

Enable an Exchange Online License

This is a pretty easy step.  Just enable the Exchange Online mailbox license for the user.  A mailbox will be provisioned, and the users will soon see the calendar icon displayed in teams.

As you onboard users to both platforms, you will need to ensure that you continue to enable Exchange Online licenses for the new users.

Pro tip: Use Azure Group-based Licensing to automate the assignment of licenses to your users.


I know, I know–already with the questions.

What if enabling an Exchange Online license didn’t cause a mailbox to be provisioned?  What if my synchronized users are still showing up as either Mail-Enabled Users or Mail-Enabled Contacts in the Exchange Admin Center?

This is likely because you previously had an Exchange on-premises environment deployed and the environment was not decommissioned correctly.

The TL;DR version of this is that:

  • Exchange is deeply integrated with Active Directory.  Exchange utilizes a number of attributes to describe the configuration of a mailbox (mailbox GUID, sever and database location, type of mailbox) as well as attributes that describe the user (proxy addresses, email address, forwarding address, and such).
  • AAD Connect synchronizes those attributes to Office 365.  It’s important for a number of reasons that a user only have one mailbox (either on-premises or online).  Exchange Online is aware of those attributes and treats the synchronized users with on-premises mailbox attributes as “mail-enabled users” or “remote mailbox users”:  it knows they have an on-premises mailbox based on the values of those attributes, so it won’t provision a mailbox in-cloud.
  • If your organization just “turned off” your Exchange environment and left those attributes in place, you’ll be in position of Active Directory and Office 365 environments thinking you still have Exchange mailboxes on-premises.  The service will prevent you from enabling what would amount to a duplicate mailbox.

There are a few ways to deal with this, such as clearing the required attributes on-premises or using AAD Connect to set the values for you.  Depending on what types of changes you want to make, you can go either of these routes.

Clearing the attributes manually

This is a pretty straightforward solution.  You’ll clear the values for the following attributes:

  • msExchMailboxGuid
  • msExchRecipientTypeDetails
  • msExchRecipientDisplayType
  • homeMDB

To do this for an individual user:

Set-ADUser -Identity <username> -Clear msExchMailboxGuid,msExchRecipientTypeDetails,msExchRecipientDisplayType,homeMDB

To do it for multiple user (such as all users in a domain):

Get-ADUser -Filter * | Set-ADUser -Identity <username> -Clear msExchMailboxGuid,msExchRecipientTypeDetails,msExchRecipientDisplayType,homeMDB

In this scenario, AAD Connect will pick up the changes and sync them to Office 365.  Bada bing, bada boom!  You’ve got cloud mailboxes (once you assign licenses).

Clearing the attributes via AAD Connect

For those that are uncomfortable updating the attributes in their on-premises environment or don’t want to run scripts against their users–never fear!  You can also accomplish this with an AAD Connect synchronization rule.

Note: You’ll want to back up your existing AAD Connect rules and follow any change control processes your organization utilizes.

  1. Launch the AAD Connect Synchronization Rules wizard.
  2. From the drop-down, select Inbound.
  3. Click Create to begin creating an inbound synchronization rule, using the following as a template:

    Name: Enter a name for the rule (required)
    Description: Enter a description for the rule (not required, but recommend)
    Connected System: Select the Active Directory forest where the users reside.
    Connected System Object Type: user
    Metaverse Object Type: person
    Link Type: join
    Precedence: Select a value lower than your lowest rule.
    Tag: Leave blank
    Enable Password Sync: leave unchecked
    Disabled: leave unchecked
  4. Click Next to advance to the Scoping filter page.
  5. You can implement a filter if you want to scope it to a single user to test it out.  This is optional.  Click Next when finished.
  6. On the Join rules page, leave it blank and click Next.
  7. Click Add transformation to add each of the following transformations:
    FlowType Target Attribute Source Apply Once Merge Type
    Expression msExchArchiveGUID AuthoritativeNull (unchecked) Update
    Expression msExchMailboxGuid AuthoritativeNull (unchecked) Update
    Expression MsExchRecipientDisplayType AuthoritativeNull (unchecked) Update
    Expression msExchRecipientTypeDetails AuthoritativeNull (unchecked) Update

  8. When you’ve finished adding all of the transformations, click Add.

In order for AAD Connect to apply this rule, you’ll need to either trigger an object to update to test or perform a Full Import task on the Active Directory Connector.  To perform a full sync from PowerShell, run this command:

Start-ADSyncSyncCycle -PolicyType Initial

Issue 3: How do I prevent users from accidentally using their new Office 365 mailbox?

You’ve now got mailboxes, but how do you prevent people from using the wrong mailbox if your organization is currently using G Suite Google Workspace?  This is also a relatively simple fix and can be done a few different ways.

For a single user:

Set-CasMailbox -Identity <test account> -UniversalOutlookEnabled $false -OutlookMobileEnabled $false -MacOutlookEnabled $false -EwsAllowOutlook $false -EwsAllowMacOutlook $false -EwsAllowEntourage $false -MAPIEnabled $false -OWAEnabled $false -ImapEnabled $false -PopEnabled $false -ActiveSyncEnabled $false

To bulk apply settings across your Office 365 tenant:

Get-Mailbox -ResultSize Unlimited | Set-CasMailbox -UniversalOutlookEnabled $false -OutlookMobileEnabled $false -MacOutlookEnabled $false -EwsAllowOutlook $false -EwsAllowMacOutlook $false -EwsAllowEntourage $false -MAPIEnabled $false  -OWAEnabled $false -ImapEnabled $false -PopEnabled $false -ActiveSyncEnabled $false

Those approaches are good, but they lack the scalability of the enterprise solution.  Instead, I’d recommend using Exchange Client Access Rules or InTune Conditional Access Policies to limit access to the mailbox.

Warning: Do not lock yourself out of administering the tenant with Client Access Rules.  Make sure you leave PowerShell enabled for at least your administrator account, should you need to change things.  You can also skip to the end to learn about using Azure Automation to run scripts at a regular interval against your new mailboxes.

$TenantAdmin = Read-Host "Enter the address of the Office 365 Global Admin"
New-ClientAccessRule -Name "Block Mailbox Access" -Action DenyAccess -AnyOfProtocols ExchangeActiveSync,ExchangeAdminCenter,IMAP,OfflineAddressBook,OutlookAnywhere,OutlookWebApp,POP3,REST,UniversalOutlook -Scope Users -Enabled $true -ExceptUsernameMatchesAnyOfPatterns $TenantAdmin

Issue 4: Teams messages are delivered to the Office 365 mailbox

Great.  Now you’ve got a mailbox for every user in Office 365 AND you’ve blocked them from being able to access them.  There’s only one problem: Teams (and other applications) are now delivering messages to the Office 365 mailbox instead of to the user’s corresponding G Suite Google Workspace mailbox.

You could try to configure a forwarding address on every mailbox to send to G Suite Google Workspace, but the main problem is that you’re sharing the domain between Office 365 and G Suite Google Workspace, so the mail won’t go anywhere.  Plus, you’d have to maintain that for EVERY mailbox, There has to be a better way.

Yes, there is.  I wrote about it in one of my first blog posts.

Memories, indeed.  But, I digress. In that original blog post, I talked about enabling two-way routing between Exchange Online and a non-Exchange platform. I’ve adapted it for use in this scenario below.

Resolution: Configure Transport Rule-Scoped Connector to Relay Mail to G Suite Google Workspace

  1. First, we need to set all of the domains to InternalRelay. Why?  When an Exchange organization (online or on-premises) is marked Authoritative for a domain, it means that it is responsible for accepting and delivering mail for that organization.  If that identity doesn’t exist in the Exchange system, it doesn’t exist period.  In the event that you have users who do exist in G Suite Google Workspace but do not get provisioned into Office 365, you’ll want to make sure they can still receive Teams meeting invitations.
    From Exchange Online PowerShell, run:

    Get-AcceptedDomain | ? {$_.DomainName -notlike "*"} | Set-AcceptedDomain -DomainType InternalRelay
  2. Next, we’re going to create a distribution list to hold the users you want excepted from this custom routing configuration.  There may not be any currently, but it’s nice to have the framework in place in the event that you have users or groups of users that want to transition mail to Office 365.
    From Exchange Online PowerShell, run:

    $ExceptionDG = (New-DistributionGroup -Name "Office 365 Users" -PrimarySmtpAddress ("Office365Users@"+((Get-AcceptedDomain)[0]).DomainName)).PrimarySmtpAddress
  3. In Exchange parlance, a connector is a configuration object that is used to (wait for it) connect mail systems or mail transfer agents.  Connectors are the plumbing used to join mail systems and to link a mail system to its next hop or route.  In this case, we’ll be creating a connector whose next hop configuration is G Suite Google Workspace (or any other platform you might be hosting mail on).
    From Exchange Online PowerShell, run:

    [array]$MxHosts = (Resolve-DnsName -Type MX (Read-Host "Enter domain name")).NameExchange
    New-OutboundConnector -Enabled:$true -ConnectorType 'Partner' -AllAcceptedDomains:$false -IsTransportRuleScoped:$true -Name 'Partner Connector to Google Workspace' -CloudServicesMailEnabled:$false -Comment 'TransportRule Scoped Connector for Google Workspace Mailoxes' -TlsSettings $null -TlsDomain $null -UseMXRecord:$false -RecipientDomains $null -SmartHosts $MxHosts
  4. Transport Rules are configuration objects that evaluate messages and take a predetermined action.  For this configuration, we’re going to check messages as they pass through the system and redirect them to the connector that was created in the previous step if they are for one of the domains that exists in both Office 365 and G Suite Google Workspace. (with the exception of the members of the distribution group we created in step 2 above).
    From Exchange Online PowerShell, run:

    New-TransportRule -SentToScope InOrganization -RouteMessageOutboundConnector 'Partner Connector to Google Workspace' -ExceptIfSentToMemberOf $ExceptionDG -Name 'Office 365 Users' -StopRuleProcessing:$false -Mode 'Enforce' -Comments 'Redirect in-org mail to Google Workspace except for members of a specific group' -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header' -SetSCL '-1' -SetHeaderName GWorkspaceRoutingRule -SetHeaderValue 1

Once this is complete, mail should flow to the G Suite Google Workspace environment for all users not in the exclusion group.

Allow a user to use Office 365 as their primary environment

At some point, your organization may decide it wants a portion of its userbase to switch to the Office 365 environment.  In the event that you want to move users from G Suite Google Workspace into Office 365, you’ll need to:

  • Add those users to the “Office 365 Users” exception group to prevent mail from being forwarded to a user’s G Suite Google Workspace address
  • Add a forwarding rule in G Suite Google Workspace for the user to send mail to
  • Update the user or tenant configuration to be able to access OWA.  In Issue 3 above, I gave two possible scenarios: modifying the individual user mailbox settings and using a client access rule.If you went the route of modifying the mailbox settings (Set-CasMailbox), you’ll just have to undo it:
    Set-CasMailbox -Identity <test account> -UniversalOutlookEnabled $true -OutlookMobileEnabled $true-MacOutlookEnabled $true-EwsAllowOutlook $true -EwsAllowMacOutlook $true -EwsAllowEntourage $true -MAPIEnabled $true -OWAEnabled $true -ImapEnabled $true-PopEnabled $true -ActiveSyncEnabled $true

    If you went the route of creating a client access rule, you’ll have to update the client access rule and add the user to the -ExceptUserNameMatchesAnyOfPatterns property:

    Set-ClientAccessRule -Name "Block Mailbox Access" -ExceptUsernameMatchesAnyOfPatterns @{add=""}

Once those pieces are complete and baked, users should be able to log into Office 365 and use it as their primary mailbox.

Issue 5: I’ve done all this, but my users are prompted to select a Time Zone when scheduling a Teams meeting

For any of your provisioned mailboxes, you may want to set the Mailbox Regional Configuration settings to reduce the number of steps a user must perform when scheduling a meeting.  The mailbox regional configuration is selected by the user the first time they log into Outlook Web App.  Since you’ve blocked that for users, they’ll never have the opportunity to set it.  This is a per-user setting.


You can configure it for a single user:

Set-MailboxRegionalConfiguration -identity <User> -Language <Language Code # or Culture Class> -TimeZone <Display Name of TimeZone>

For example, if you want to set the mailbox configuration for English language in the Eastern time zone:

Set-MailboxRegionalConfiguration -identity <User> -Language 1033 -TimeZone "Eastern Standard Time"

To bulk apply settings across your Office 365 tenant:

Get-Mailbox -ResultSize Unlimited | Set-MailboxRegionalConfiguration -Language <Language Code # or Culture Class> -TimeZone <DisplayName of TimeZone>

Language Values

The possible values for the Language parameter (based on the Microsoft Locale ID values table):

Language (Locale) Code
Arabic (Algeria) 5121
Arabic (Bahrain) 15361
Arabic (Egypt) 3073
Arabic (Iraq) 2049
Arabic (Jordan) 11265
Arabic (Kuwait) 13313
Arabic (Lebanon) 12289
Arabic (Libya) 4097
Arabic (Morocco) 6145
Arabic (Oman) 8193
Arabic (Qatar) 16385
Arabic (Saudi Arabia) 1025
Arabic (Syria) 10241
Arabic (Tunisia) 7169
Arabic (U.A.E.) 14337
Arabic (Yemen) 9217
Basque 1069
Bulgarian 1026
Catalan 1027
Chinese (Hong Kong S.A.R) 3076
Chinese (Macau S.A.R) 5124
Chinese (People’s Republic of China) 2052
Chinese (Singapore) 4100
Chinese (Taiwan) 1028
Croatian 1050
Czech 1029
Danish 1030
Dutch (Belgium) 2067
Dutch (Netherlands) 1043
English (Australia) 3081
English (Belize) 10249
English (Canada) 4105
English (Caribbean) 9225
English (Ireland) 6153
English (Jamaica) 8201
English (New Zealand) 5129
English (Republic of the Philippines) 13321
English (South Africa) 7177
English (Trinidad) 11273
English (United Kingdom) 2057
English (United States) 1033
English (Zimbabwe) 12297
Estonian 1061
Filipino (Philippines) 1124
Finnish 1035
French (Belgium) 2060
French (Canada) 3084
French (France) 1036
French (Luxembourg) 5132
French (Principality of Monaco) 6156
French (Switzerland) 4108
German (Austria) 3079
German (Germany) 1031
German (Liechtenstein) 5127
German (Luxembourg) 4103
German (Switzerland) 2055
Greek 1032
Hebrew 1037
Hindi 1081
Hungarian 1038
Icelandic 1039
Indonesian 1057
Italian (Italy) 1040
Italian (Switzerland) 2064
Japanese 1041
Kazakh 1087
Korean 1042
Latvian 1062
Lithuanian 1063
Malay 1086
Norwegian (Bokmål) 1044
Persian 1065
Polish 1045
Portuguese (Brazil) 1046
Portuguese (Portugal) 2070
Romanian 1048
Russian 1049
Serbian (Cyrillic) 3098
Serbian (Latin) 2074
Slovak 1051
Slovenian 1060
Spanish (Argentina) 11274
Spanish (Bolivia) 16394
Spanish (Chile) 13322
Spanish (Colombia) 9226
Spanish (Costa Rica) 5130
Spanish (Dominican Republic) 7178
Spanish (Ecuador) 12298
Spanish (El Salvador) 17418
Spanish (Guatemala) 4106
Spanish (Honduras) 18442
Spanish (Mexico) 2058
Spanish (Nicaragua) 19466
Spanish (Panama) 6154
Spanish (Paraguay) 15370
Spanish (Peru) 10250
Spanish (Puerto Rico) 20490
Spanish (International Sort) 3082
Spanish (Traditional Sort) 1034
Spanish (Uruguay) 14346
Spanish (Venezuela) 8202
Swedish (Finland) 2077
Swedish (Sweden) 1053
Thai 1054
Turkish 1055
Ukrainian 1058
Urdu 1056
Vietnamese 1066

You can also use the corresponding culture value pairs, such as en-us.

Pro tip: If you’re setting the Language value to a non-English language, you can also use the -LocalizeDefaultFolderName switch parameter to update the names of the default folder (Inbox, Calendar, Sent Items, etc).

TimeZone values

The possible values for the TimeZones parameter can be retrieved using the following command from a PowerShell console:

$TimeZone = Get-ChildItem "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Time zones" | foreach {Get-ItemProperty $_.PSPath}; $TimeZone | sort Display | Format-Table -Auto @{L="TimeZoneName";E={$_.PSChildname}},Display

Use the value in the TimeZone column in the Set-MailboxRegionalConfiguration -Timezone parameter.

TimeZone Display
UTC (UTC) Coordinated Universal Time
GMT Standard Time (UTC+00:00) Dublin, Edinburgh, Lisbon, London
Greenwich Standard Time (UTC+00:00) Monrovia, Reykjavik
Sao Tome Standard Time (UTC+00:00) Sao Tome
W. Europe Standard Time (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
Central Europe Standard Time (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague
Romance Standard Time (UTC+01:00) Brussels, Copenhagen, Madrid, Paris
Morocco Standard Time (UTC+01:00) Casablanca
Central European Standard Time (UTC+01:00) Sarajevo, Skopje, Warsaw, Zagreb
W. Central Africa Standard Time (UTC+01:00) West Central Africa
Jordan Standard Time (UTC+02:00) Amman
GTB Standard Time (UTC+02:00) Athens, Bucharest
Middle East Standard Time (UTC+02:00) Beirut
Egypt Standard Time (UTC+02:00) Cairo
E. Europe Standard Time (UTC+02:00) Chisinau
Syria Standard Time (UTC+02:00) Damascus
West Bank Standard Time (UTC+02:00) Gaza, Hebron
South Africa Standard Time (UTC+02:00) Harare, Pretoria
FLE Standard Time (UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius
Israel Standard Time (UTC+02:00) Jerusalem
Kaliningrad Standard Time (UTC+02:00) Kaliningrad
Sudan Standard Time (UTC+02:00) Khartoum
Libya Standard Time (UTC+02:00) Tripoli
Namibia Standard Time (UTC+02:00) Windhoek
Arabic Standard Time (UTC+03:00) Baghdad
Turkey Standard Time (UTC+03:00) Istanbul
Arab Standard Time (UTC+03:00) Kuwait, Riyadh
Belarus Standard Time (UTC+03:00) Minsk
Russian Standard Time (UTC+03:00) Moscow, St. Petersburg
E. Africa Standard Time (UTC+03:00) Nairobi
Iran Standard Time (UTC+03:30) Tehran
Arabian Standard Time (UTC+04:00) Abu Dhabi, Muscat
Astrakhan Standard Time (UTC+04:00) Astrakhan, Ulyanovsk
Azerbaijan Standard Time (UTC+04:00) Baku
Russia Time Zone 3 (UTC+04:00) Izhevsk, Samara
Mauritius Standard Time (UTC+04:00) Port Louis
Saratov Standard Time (UTC+04:00) Saratov
Georgian Standard Time (UTC+04:00) Tbilisi
Volgograd Standard Time (UTC+04:00) Volgograd
Caucasus Standard Time (UTC+04:00) Yerevan
Afghanistan Standard Time (UTC+04:30) Kabul
West Asia Standard Time (UTC+05:00) Ashgabat, Tashkent
Ekaterinburg Standard Time (UTC+05:00) Ekaterinburg
Pakistan Standard Time (UTC+05:00) Islamabad, Karachi
Qyzylorda Standard Time (UTC+05:00) Qyzylorda
India Standard Time (UTC+05:30) Chennai, Kolkata, Mumbai, New Delhi
Sri Lanka Standard Time (UTC+05:30) Sri Jayawardenepura
Nepal Standard Time (UTC+05:45) Kathmandu
Central Asia Standard Time (UTC+06:00) Astana
Bangladesh Standard Time (UTC+06:00) Dhaka
Omsk Standard Time (UTC+06:00) Omsk
Myanmar Standard Time (UTC+06:30) Yangon (Rangoon)
SE Asia Standard Time (UTC+07:00) Bangkok, Hanoi, Jakarta
Altai Standard Time (UTC+07:00) Barnaul, Gorno-Altaysk
W. Mongolia Standard Time (UTC+07:00) Hovd
North Asia Standard Time (UTC+07:00) Krasnoyarsk
N. Central Asia Standard Time (UTC+07:00) Novosibirsk
Tomsk Standard Time (UTC+07:00) Tomsk
China Standard Time (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi
North Asia East Standard Time (UTC+08:00) Irkutsk
Singapore Standard Time (UTC+08:00) Kuala Lumpur, Singapore
W. Australia Standard Time (UTC+08:00) Perth
Taipei Standard Time (UTC+08:00) Taipei
Ulaanbaatar Standard Time (UTC+08:00) Ulaanbaatar
Aus Central W. Standard Time (UTC+08:45) Eucla
Transbaikal Standard Time (UTC+09:00) Chita
Tokyo Standard Time (UTC+09:00) Osaka, Sapporo, Tokyo
North Korea Standard Time (UTC+09:00) Pyongyang
Korea Standard Time (UTC+09:00) Seoul
Yakutsk Standard Time (UTC+09:00) Yakutsk
Cen. Australia Standard Time (UTC+09:30) Adelaide
AUS Central Standard Time (UTC+09:30) Darwin
E. Australia Standard Time (UTC+10:00) Brisbane
AUS Eastern Standard Time (UTC+10:00) Canberra, Melbourne, Sydney
West Pacific Standard Time (UTC+10:00) Guam, Port Moresby
Tasmania Standard Time (UTC+10:00) Hobart
Vladivostok Standard Time (UTC+10:00) Vladivostok
Lord Howe Standard Time (UTC+10:30) Lord Howe Island
Bougainville Standard Time (UTC+11:00) Bougainville Island
Russia Time Zone 10 (UTC+11:00) Chokurdakh
Magadan Standard Time (UTC+11:00) Magadan
Norfolk Standard Time (UTC+11:00) Norfolk Island
Sakhalin Standard Time (UTC+11:00) Sakhalin
Central Pacific Standard Time (UTC+11:00) Solomon Is., New Caledonia
Russia Time Zone 11 (UTC+12:00) Anadyr, Petropavlovsk-Kamchatsky
New Zealand Standard Time (UTC+12:00) Auckland, Wellington
UTC+12 (UTC+12:00) Coordinated Universal Time+12
Fiji Standard Time (UTC+12:00) Fiji
Kamchatka Standard Time (UTC+12:00) Petropavlovsk-Kamchatsky – Old
Chatham Islands Standard Time (UTC+12:45) Chatham Islands
UTC+13 (UTC+13:00) Coordinated Universal Time+13
Tonga Standard Time (UTC+13:00) Nuku’alofa
Samoa Standard Time (UTC+13:00) Samoa
Line Islands Standard Time (UTC+14:00) Kiritimati Island
Azores Standard Time (UTC-01:00) Azores
Cape Verde Standard Time (UTC-01:00) Cabo Verde Is.
UTC-02 (UTC-02:00) Coordinated Universal Time-02
Mid-Atlantic Standard Time (UTC-02:00) Mid-Atlantic – Old
Tocantins Standard Time (UTC-03:00) Araguaina
E. South America Standard Time (UTC-03:00) Brasilia
SA Eastern Standard Time (UTC-03:00) Cayenne, Fortaleza
Argentina Standard Time (UTC-03:00) City of Buenos Aires
Greenland Standard Time (UTC-03:00) Greenland
Montevideo Standard Time (UTC-03:00) Montevideo
Magallanes Standard Time (UTC-03:00) Punta Arenas
Saint Pierre Standard Time (UTC-03:00) Saint Pierre and Miquelon
Bahia Standard Time (UTC-03:00) Salvador
Newfoundland Standard Time (UTC-03:30) Newfoundland
Paraguay Standard Time (UTC-04:00) Asuncion
Atlantic Standard Time (UTC-04:00) Atlantic Time (Canada)
Venezuela Standard Time (UTC-04:00) Caracas
Central Brazilian Standard Time (UTC-04:00) Cuiaba
SA Western Standard Time (UTC-04:00) Georgetown, La Paz, Manaus, San Juan
Pacific SA Standard Time (UTC-04:00) Santiago
SA Pacific Standard Time (UTC-05:00) Bogota, Lima, Quito, Rio Branco
Eastern Standard Time (Mexico) (UTC-05:00) Chetumal
Eastern Standard Time (UTC-05:00) Eastern Time (US & Canada)
Haiti Standard Time (UTC-05:00) Haiti
Cuba Standard Time (UTC-05:00) Havana
US Eastern Standard Time (UTC-05:00) Indiana (East)
Turks And Caicos Standard Time (UTC-05:00) Turks and Caicos
Central America Standard Time (UTC-06:00) Central America
Central Standard Time (UTC-06:00) Central Time (US & Canada)
Easter Island Standard Time (UTC-06:00) Easter Island
Central Standard Time (Mexico) (UTC-06:00) Guadalajara, Mexico City, Monterrey
Canada Central Standard Time (UTC-06:00) Saskatchewan
US Mountain Standard Time (UTC-07:00) Arizona
Mountain Standard Time (Mexico) (UTC-07:00) Chihuahua, La Paz, Mazatlan
Mountain Standard Time (UTC-07:00) Mountain Time (US & Canada)
Pacific Standard Time (Mexico) (UTC-08:00) Baja California
UTC-08 (UTC-08:00) Coordinated Universal Time-08
Pacific Standard Time (UTC-08:00) Pacific Time (US & Canada)
Alaskan Standard Time (UTC-09:00) Alaska
UTC-09 (UTC-09:00) Coordinated Universal Time-09
Marquesas Standard Time (UTC-09:30) Marquesas Islands
Aleutian Standard Time (UTC-10:00) Aleutian Islands
Hawaiian Standard Time (UTC-10:00) Hawaii
UTC-11 (UTC-11:00) Coordinated Universal Time-11
Dateline Standard Time (UTC-12:00) International Date Line West

As previously mentioned, regional mailbox configurations settings are per-user.  As you go through the normal operations of adding users to your environment, you’ll need to revisit this process.

Issue 6: G Suite Google Workspace Users Receive Meeting Invitations with Blank Subjects

While working with one of my customers, an issue was raised that G Suite Google Workspace users were receiving meeting invitations generated by Teams with blank subject lines.


You likely need to set the Transport Neutral Encapsulation Format (TNEF) option manually.  To do so, connect to Exchange Online via PowerShell and run this:

Set-RemoteDomain -Identity Default -TNEFEnabled $false

That will update the TNEF setting for all remote domains (likely not an issue if you’re only using Office 365 for Teams meetings and collaboration features but have your mail routed to G Suite Google Workspace ).

Issue 7: Meetings scheduled in Teams don’t show up on Organizer’s G Suite Google Workspace calendar

This one is a bit more tricky.  When you are scheduling a meeting via Outlook, the invitees are sent an an invitation email.  As the organizer, however, no email is ever generated–the meeting just “shows up” in your calendar.  The same holds true with Teams–it directly writes to organizer’s Exchange Online calendar and never generates an outbound email to to the organizer.  So, since no meeting email is sent to the organizer, there’s nothing in the transport pipeline that will get delivered to the G Suite Google Workspace external mailbox.

The easiest way to work around this is to use either the Microsoft Teams Meeting Add-on for G Suite or Outlook with the Teams Plug-In to schedule the meeting.  Outlook can be configured with the local G Suite Google Workspace mailbox, but the Teams plug-in will connect to Exchange Online.  Outlook will create the meeting in the “local” G Suite Google Workspace calendar and the Teams plug-in will handle the meeting invitation links for the rest of the users.

Issue 8: Meetings scheduled in Teams don’t show up in recipient’s calendar in Teams

As mentioned previously, the requirements to get the “shared calendaring” experience to work:

  • All users must be licensed for Exchange Online.
  • Meeting organizers should primarily use Outlook (connected to G Suite Google Workspace as the primary mailbox) with the Teams plug-in enabled in order to get the meeting to show up.

However, when users want to check their own calendar in Teams, only meetings that they organize will show up there.  This is due to the configuration made in Issue 4. The basis of the configuration is that all Office 365-based messages that go through the transport pipeline will bypass the local Office 365 mailbox and be delivered directly to G Suite Google Workspace. This configuration is the simplest, most low-maintenance way to ensure that all messages are delivered for all users without having to individually configure mail forwarding rules.

However, this also means that users will be unable to see Teams calendar items in their Office 365 / Exchange Online / Teams calendar views (except for meetings that they organize).


There is no simple resolution, but there are two potential solutions (at this time):

Synchronization Method

As pointed out earlier, you can attempt to synchronize calendars using third party tools per Issue 2. This would allow calendar items to be written from the user’s G suite Google Workspace mailbox to their corresponding Exchange Online mailbox.

Individual Mailbox Forwarding Method

The other potential solution is to not perform the transport rule scoped connector configuration discussed in issue 4, but instead to apply a secondary routing address to the G Suite Google Workspace mailboxes (such as and then use the Set-Mailbox cmdlet to update each Exchange Online user’s mailbox to forward to the corresponding G suite Google Workspace mailbox:

Set-Mailbox -Identity -DeliverToMailboxAndForward $True -ForwardingSmtpAddress

This method is very high-touch and requires maintaining a mapping between Exchange Online and G Suite Google Workspace mailboxes.  If you want to test this method out, you can also modify the transport rule associated with this configuration and exclude test users.

This is probably the most frustrating and confusing issue overall to deal with.  You might have the best end-user and service desk experience if you instruct your G Suite Google Workspace users to only schedule meetings in the G Suite Google Workspace interface (with the Microsoft Teams add-on) or with Outlook (with the Microsoft Teams plug-in) and disable the calendar icon from showing up in Teams at all for users that primarily use the G Suite Google Workspace platform.

Issue 9: G Suite Google Workspace places messages sent from Office 365 in spam/junk mail

In this scenario, when messages are being delivered from Office 365 to G Suite Google Workspace , G Suite’s Google Workspace’s message hygiene policies (I use that term broadly to cover spam, spoof, and phish) may place the messages into the user’s spam/junk folders or in quarantine.  This is likely due to a combination of SPF, DKIM, and DMARC settings.

What’s likely happening is that your organization has configured one of the three message authentication and verification settings (SPF, DKIM, or DMARC) to designate ‘permitted senders’ for your domain(s).  These settings may have been configured on only reflect internal message relay systems or G Suite Google Workspace as being verified to send using your return address domains.  When G Suite Google Workspace receives a message from Office 365 with a return/reply address matching your G Suite Google Workspace domain, it may get flagged as spam or a spoofed message.


Update your SPF, DKIM, and DMARC policies in your organization’s external DNS to include Office 365.  For examples of how to do this, see: Exchange Online Protection (EOP) Best Practices and Recommendations.

Issue 10: Microsoft Teams Calendar Add-on for G Suite Google Workspace returning ‘disabled’ error

Scenario: You have users that are attempting to use the Microsoft Teams Calendar Add-on for G Suite Google Workspace (available in the Google Marketplace) and they receive the following error message:

Sorry, but we’re having trouble signing you in.

AADSTS7000112: Application ‘7969c887-ba98-48bb-8832-6c9239929d7c'(Microsoft Teams meeting add-on for Google Workspace) is disabled.

It’s likely because the AppID in the Office 365 tenant that they’re connecting to has been disabled, preventing the application from being allowed to access the environment.

To resolve the issue, you’ll need to enable the AppID in Enterprise Applications in the Azure portal for the tenant or via Azure AD PowerShell by following the steps earlier in this post.

Issue 11: Troubleshooting mail delivery issues

In addition to troubleshooting messages ending up in spam on the G Suite Google Workspace site, you may end up with problems where messages get delivered to the local Office 365 mailboxes.  This is typically due to Exchange evaluating the recipient as ‘not in scope’ for the transport rule or something else happening before the G Suite Google Workspace routing transport rule takes over.

I’ve updated the New-TransportRule snippet above to include stamping a header on the messages that have been processed by the rule. If you already deployed the transport rule and want to amend it, you can do this from PowerShell:

Get-TransportRule 'Google Workspace routing*' |Set-TransportRule -SetHeaderName GWorkspaceRoutingRule -SetHeaderValue 1

Then, once you start testing sending messages or meeting requests that end up in the recipient’s mailbox, you can check the message trace or header properties of the message to see if it’s been stamped with the header.  If the header is not present, then the message did not trip the rule and you have a starting place.

Issue 12: Suppressing NDR and DSN messages

Suppose you send a meeting invitations from Teams and are requesting confirmation (accept/decline) from the G Suite Google Workspace recipient. Except you have a transport rule in place to route mail back out.  This may cause Delivery Status Notification (DSN) or Non-Delivery Report (NDR) messages to be generated.

A couple of notes or things to try:

Suppress NDR

You can attempt to suppress those messages with the following transport rule:

New-TransportRule -Name "Suppress NDRs and DSNs" -Comments "Suppress NDRs and DSNs" -SubjectOrBodyMatchesPatterns @('Delivery Status Notification','Failure notice','Delivery failed','There was an error sending your mail','There was an issue sending your message','Delivery has failed to these recipients or groups','Hop count exceeded') -DeleteMessage $True

You’ll likely want to make this rule the top priority rule.  Note that it will affect all messages tenant wide, so if you have other folks using this environment who are not routing their messages to G Suite Google Workspace, you’ll likely suppress all NDRs and DSNs.  You’ll also suppress valid messages, so I wouldn’t recommend implementing this unless you’re getting a lot of these messages (like ‘hop count exceeded’ or ‘delivery failed’).

Catch-All Mailbox for Responses to Teams Channel Meeting requests

Teams in the Government Community Cloud (GCC) does not have the ‘Email a channel’ functionality.  Thus, when you generate channel meetings in Teams and send the meeting requests out to external recipients, the responses are non-deliverable.  You can attempt to curtail this behavior by creating a Catch-All mailbox for inbound mail.

New-Mailbox -Shared -Alias 'catchall' -Name "Catch-All Mailbox" -DisplayName "Catch-All Mailbox" -Force

New-DynamicDistributionGroup -Name 'AllMailboxes' -Alias 'AllMailboxes' -OrganizationalUnit $null -IncludedRecipients 'MailboxUsers'

New-TransportRule -FromScope 'NotInOrganization' -RedirectMessageTo 'catchall' -ExceptIfSentToMemberOf AllMailboxes -Name 'AllMailboxes' -StopRuleProcessing:$false -Mode 'Enforce' -Comments 'Catch-all mailbox rule' -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header'

Depending on the size of your organization, this filter may take a long time to take effect.

Known Issues

As it’s been alluded to a few times in this article, free/busy is a difficult issue at this time. Here are the caveats of what does/doesn’t work or what the experiences look like:

  • Meeting organizers using the Teams application to schedule meetings will see free/busy of others on the Teams platform, but it will likely not represent the recipients’ actual free/busy if the recipients are using G Suite Google Workspace for their calendaring.  The Teams recipient calendars will be empty, because the meeting invitation has been forwarded to their G Suite Google Workspace mailbox (if you’re using the transport rule method).  You can get around this by using Set-Mailbox method to individually forward meeting invitations, but it may not be scalable for large organizations.
  • Meeting recipients using the Teams application to check their calendars will not see Teams meetings to which they’ve been invited (unless they’ve copied or synced them from their G Suite Google Workspace calendar).


Some of these settings (like mailbox regional configuration and enabled protocols) are per-mailbox settings, which means you need to redo them on a regular bases as you onboard more mailboxes.

You can use Azure Automation to help with this.  After assigning users licenses with Group-based Licensing as I recommend earlier in this post, you could use my Azure Automation blog post to help configure additional settings:

You’ll want to make sure you install the SharePoint Online and Exchange Online modules and tidy up your code for connecting to both of those and that you’ve created an automation credential.  In this example, my Office 365 service credential object is called the very original Office365ServiceAccount-Credential.  I’m going to be configuring all mailboxes with the English locale and the Eastern time zone.

Then, something like this as part of your script:

$Credential = Get-AutomationPSCredential -Name "Office365ServiceAccount-Credential"

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $Credential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking -Name ExSession
Connect-SPOService -Url https://<tenant> -Credential $Credential

$Date = (Get-Date).AddDays(-2)
$Users = (Get-Mailbox -Filter "WhenMailboxCreated -gt '$Date'").PrimarySmtpAddress

# Update user settings
Foreach ($User in $Users)
     # Block access to mailbox
     Set-CasMailbox -UniversalOutlookEnabled $false -OutlookMobileEnabled $false -MacOutlookEnabled $false -EwsAllowOutlook $false -EwsAllowMacOutlook $false -EwsAllowEntourage $false -MAPIEnabled $false  -OWAEnabled $false -ImapEnabled $false -PopEnabled $false -ActiveSyncEnabled $false

     # Update Exchange Regional Settings
     Set-MailboxRegionalConfiguration -Identity $User -Language 1033 -TimeZone "Eastern Standard Time"     

     # PreProvision User OneDrive site
     Request-SPOPersonalSite -UserEmails $User

Go forth.


Published by Aaron Guilmette

Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese.

Reader Comments

  1. Thank you for such a brilliant guide. I’ve got the teams addon for Google calendar working now!

    With regard to issue 2 – Is it best as all our users are on google with to then create the 365 accounts with or with the publicly known domain name?

    I am stuck with Issue 4 – point 3. I believe I need to install the DnsClient module but can’t figure our how to do this. I have tried:
    Import-module -name DnsClient
    Which give the error:
    Import-Module: The specified module ‘DnsClient’ was not loaded because no valid module file was found in any module directory.

    We are using the default Office 365 Business Standard setup.

    1. Our instructions that we provide for EDU depend on two different domains, but that’s not necessarily feasible for a lot of customers in this boat. That’s why I wrote the guide. Having different domains breaks the sign-in experience (users have to remember two sign-ins) as well as mail routing. If you need to live in both worlds, I’d recommend using these steps as a *complete* solution, since I put them together as such (so, use the same domain on both sides). Otherwise, the ETRs will not work for you (since neither us nor Google have address rewriting capabilities native in our respective platforms).

      If you can’t get Resolve-DnsName to complete successfully, you can just create an array object with your MX host names:

      [array]$MXHosts = @(‘’,’’)

      Or, you can try using NSLookup to build the MX Hosts variable:
      $temp = (nslookup -q=mx
      [array]$MXHosts = $temp | % {$_ | ? {$_-match “MX preference”}} | % {($_.Split(“=”)[2]).Trim()}

      Either way, the result should be an array object with one domain per entry.

  2. Hi Aaron,

    thanks for the writeup. Finally found a place where most pieces of the puzzle are combined in 1 post 😉

    We’re in the process of using AAD as idp but we’re still using gmail as our email provider.

    Can’t help but feel the whole sso process is half-baked though.

    – myaccount/mysignins/myapps/… every click in the interface sends a user to a different subdomain
    – we don’t seem to have any control over the ‘my groups’ tab, short from disallowing group viewing and creation for our students.
    – even though we can lock users out of outlook (thanks for the handy oneliner btw), there seems to be no way to hide the outlook owa app alltogether. Disabling the exchange online license for a user does the trick, but this would cripple the whole teams scheduling solution. Any ideas?

    end rant 😉

    1. Glad you found it helpful!

      You can use AAD as the IDP/SSO to Google, if you’re interested in configuring that, too (if that’s not what you meant you already had done).

      Yeah, you’re kinda stuck there. We don’t support managing the App Launcher aside from adding new items (global) or the add/remove license (which is tied to the feature).

  3. Hi Aaron,
    Thank you for the great article. I tried to resolve issue 4 but I received the below message in the Powershell.

    WARNING: There is no outbound connector to deliver mail for this domain. Make sure that there’s an Outbound Connector of the type OnPremises that matches every ‘internal relay’ accepted domain. The connector can either have the All Accepted Domains flag enabled or have a recipient domain that matches the accepted domain.

    Could you please guide me?

    1. I received the below message too

      Unable to find outbound connector with the following identity: ‘Partner Connector to G Suite’.
      + CategoryInfo : InvalidArgument: (RouteMessageOutboundConnector:String) [New-TransportRule], ArgumentException
      + FullyQualifiedErrorId : [Server=AS8PR08MB6295,RequestId=49ad7d9a-efad-40d8-a9ba-d7657c7f1865,TimeStamp=16-01-2021 07:50:08] [FailureCategory=Cmdlet-ArgumentException] 5672141D,Microsoft.Exchange.MessagingPolicies.Rules.Tasks.NewTransportRule
      + PSComputerName :

      1. Figured it myself. There’s a minor typo in the PowerShell code in the fourth point.
        At present, it is:

        New-TransportRule -SentToScope InOrganization -RouteMessageOutboundConnector ‘Partner Connector to G Suite’ -ExceptIfSentToMemberOf $ExceptionDG -Name ‘G Suite Routing’ -StopRuleProcessing:$false -Mode ‘Enforce’ -Comments ‘Redirect in-org mail to G Suite except for members of a specific group’ -RuleErrorAction ‘Ignore’ -SenderAddressLocation ‘Header’ -SetSCL ‘-1’

        It should be:
        New-TransportRule -SentToScope InOrganization -RouteMessageOutboundConnector ‘Partner Connector to GSuite’ -ExceptIfSentToMemberOf $ExceptionDG -Name ‘G Suite Routing’ -StopRuleProcessing:$false -Mode ‘Enforce’ -Comments ‘Redirect in-org mail to G Suite except for members of a specific group’ -RuleErrorAction ‘Ignore’ -SenderAddressLocation ‘Header’ -SetSCL ‘-1’

        Basically, there is a extra space between ‘GSuite’ in the Outbound Connector name 🙂

  4. Aaron – wow, this article is incredible! Thanks for sharing your experiences!

    We’re a small GSuite customer (<500) very close to getting our M365 tenant with the goal of getting Teams running (with Gmail backend) first, then later moving folks native to Exchange.

    Issue 2 / removing old exchange attribute artifacts applies to us. We had Exchange in-house many years ago. In addition to the attributes you mentioned, I noticed our users have 4 more EmsExch values filled in:


    Since we aren't using Exchange, I'm assuming these are safe to clear (ideally best to clear) as well?

    1. If you don’t have Exchange on-premises anymore, you can get rid of those (the only one that matters in that list is MsExchHomeServerName). If you sync your identity from your current AD to O365, you’ll need to basically make your users look like mail enabled users (msExchRecipientDisplayType 6 and msExchRecipientTypeDetails 128) and nuke the msExchMailboxGuid if you have it as well–otherwise Office 365 will provision you cloud user as a mail user awaiting on-premises Exchange mailbox migration.

  5. Thanks Aaron!
    This is exactly what I needed for my organisation. Issue 4 is game changer for me and allows a proper usage of Teams in GSuite environnement 🙂
    Greatly appreciated!!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.