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 August 19, 2020:

May 27, 2020 – Issue 6: Resolving blank subjects for Teams meetings received by G Suite
August 19, 2020 – Issue 7: Meetings scheduled in Teams don’t show up on Organizer’s G Suite calendar
August 19, 2020 – Issue 8: Meetings scheduled in Teams don’t show up in recipient’s calendar in Teams
August 19, 2020 – Issue 9: G Suite places messages sent from Office 365 in spam/junk mail

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!

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 GSuite' -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'

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

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 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 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, one of 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.

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.

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.