With the rise of stay-at-home orders due to COVID-19 over the past several weeks (now turned months), 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 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.

Note: This post has some new updates, as of April 29, 2021:

April 29, 2021 – Allow a user to use Office 365 as their primary environment
February 4, 2021 – Issue 12: Suppressing NDR and DSN messages
February 4, 2021 – Issue 11: Troubleshooting mail delivery issues
January 29, 2021 – Microsoft Teams Calendar Add-on for G Suite
January 29, 2021 – Issue 10: Microsoft Teams Calendar Add-on for G Suite returning ‘disabled’ error
August 19, 2020 – Issue 9: G Suite places messages sent from Office 365 in spam/junk mail
August 19, 2020 – Issue 8: Meetings scheduled in Teams don’t show up in recipient’s calendar in Teams
August 19, 2020 – Issue 7: Meetings scheduled in Teams don’t show up on Organizer’s G Suite calendar
May 27, 2020 – Issue 6: Resolving blank subjects for Teams meetings received by G Suite

Introduction

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 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, though you can also use Azure Active Directory to provision G Suite 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 https://docs.microsoft.com/en-us/microsoft-365/education/deploy/enabling-teams-for-education-for-google-users, 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 a docs article and relies on configuring normal things like transport rules or using the Teams plug-in for Outlook, this is not supported by Microsoft support.  It’s best effort only 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

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.  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 users can individually deploy this add-in to their G Suite 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 calendar (pro-tip: it also works with consumer GMail).

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 mailboxes.

Admin

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

1. Open the Azure portal (https://portal.azure.com).
2. Navigate to Enterprise applications | All applications (https://portal.azure.com/#blade/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AllApps/menuId/).
   
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
      } 
      else 
      {
        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
   } 
 else 
   {
     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.

End-User

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

1. Log into the G Suite 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 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 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 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 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 (https://admin.microsoft.com), 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?

This:

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 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 (https://admin.microsoft.com), 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 tenant.onmicrosoft.com) 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 (onmicrosoft.com domain)"
$Credential = Get-Credential -Message "Enter Office 365 Global Admin Credential"
Connect-MsolService -Credential $Credential
$Tenant = "https://"+$tenantname.split(".")[0]+"-admin.sharepoint.com"
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 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, 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 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.

Troubleshooting

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?  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 mailbox.

You could try to configure a forwarding address on every mailbox to send to G Suite, but the main problem is that you’re sharing the domain between Office 365 and G Suite, 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

1. First, we need to set all of the non-onmicrosoft.com 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 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 "*onmicrosoft.com"} | 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 (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 G Suite' -CloudServicesMailEnabled:$false -Comment 'TransportRule Scoped Connector for G Suite 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. (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 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' -SetHeaderName GSuiteRoutingRule -SetHeaderValue 1

Once this is complete, mail should flow to the G Suite 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 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 address
• Add a forwarding rule in G Suite for the user to send mail to user@tenant.onmicrosoft.com
• 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="testacount@domain.com"}

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.

Resolution

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):

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.

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 Users Receive Meeting Invitations with Blank Subjects

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

Resolution

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).

Issue 7: Meetings scheduled in Teams don’t show up on Organizer’s G Suite 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 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 mailbox, but the Teams plug-in will connect to Exchange Online.  Outlook will create the meeting in the “local” G Suite 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 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. 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).

Resolution

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 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 mailboxes (such as user@routing.domain.com) and then use the Set-Mailbox cmdlet to update each Exchange Online user’s mailbox to forward to the corresponding G suite mailbox:

Set-Mailbox -Identity User2@domain.com -DeliverToMailboxAndForward $True -ForwardingSmtpAddress User2@routing.domain.com

This method is very high-touch and requires maintaining a mapping between Exchange Online and G Suite 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 users to only schedule meetings in the G Suite 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 platform.

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

In this scenario, when messages are being delivered from Office 365 to G Suite, G Suite’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 as being verified to send using your return address domains.  When G Suite receives a message from Office 365 with a return/reply address matching your G Suite domain, it may get flagged as spam or a spoofed message.

Resolution

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 returning ‘disabled’ error

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

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 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 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 'g suite routing*' |Set-TransportRule -SetHeaderName GSuiteRoutingRule -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 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, 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 for their calendaring.  The Teams recipient calendars will be empty, because the meeting invitation has been forwarded to their G Suite 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 calendar).

Automation

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 https://outlook.office365.com/powershell-liveid/ -Credential $Credential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking -Name ExSession
Connect-SPOService -Url https://<tenant>-admin.sharepoint.com -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.