Google Workspace (G-Suite) and Exchange Online Free/Busy Sharing using the Google Calendar Interop Tool

In this blog post I’ll be detailing my walkthrough of the process of sharing free/busy information between Google Workspace (G-Suite) and Microsoft Exchange Online.

Google runs the show in this setup and the process is laid out here: Allow Calendar users to see Exchange availability data – Google Workspace Admin Help.  I needed to test the procedure as it would be needed for a project I’m working on regarding a new acquisition.  The setup I used is the same one I used for the Google Workspace to Exchange Online mailbox migration, so you can get the details regarding the setup from that blog post, but a quick summary is as follows:

I setup one trial M365 tenant and one trial G-Suite Workspace like this:

  • gwtoexo.ml – Exchange Online domain
  • acquired.ml – Google Workspace domain

After I created the trial and setup the domains properly in G-Suite and M365, I created some test users on the Google side as well as in the Microsoft tenant.  Office Space characters make the best test users in my opinion….

The Google Calendar Interop supports both basic authentication for Exchange as well as OAuth 2.0 for Exchange Online.  While OAuth 2.0 won’t work for on-prem Exchange, basic authentication does work for Exchange Online and might be the better approach depending on your viewpoint.

In the first part of the Google documentation “Allow Calendar users to see Exchange availability data”, they go over how the Exchange users should be setup and configuring the Google Interoperability for Calendar.  In Step 1, they detail that your Exchange users will need an associated mailbox as well the G-Suite users on the other side.  My testing of the free/busy was right after I migrated some users from G-Suite to Exchange online, so here make sure you turn the Google Calendar off for the migrated user as they will still have a mailbox in G-Suite after a G-Suite to Exchange Online migration if you are using the Microsoft migration method.  Also, because I did a migration earlier, a user domain alias was previously setup for the users in G-Suite.

If you only need basic availability times returned without any event details, you can skip the step for “Turn on full event detail lookups”.  If you want limited event details, you’ll need to run the following per Google’s documentation:

You can expose limited event details for an individual mailbox using the following command:

Set-MailboxFolderPermission -Identity ($Mailbox.Alias + ‘:\calendar’) -User Default -AccessRights LimitedDetails

For all mailboxes, use this command:

ForEach ($Mailbox in @(Get-Mailbox -ResultSize Unlimited)) {Set-MailboxFolderPermission –Identity ($Mailbox.Alias+’:\calendar’) –User Default –AccessRights LimitedDetails}

For my testing, I ran this across all the mailboxes:

The Step 2 regarding Exchange Internet connectivity in the Google documentation can be skipped.  If you are using Exchange on-prem and want to lock down IP ranges that can connect, Google provides these details.

Step 3 is where you need to create the Exchange role account.  This account is a low privileged account with an associated user mailbox.  Think of this account as a proxy for performing the free/busy lookups.  By that I mean, within an Exchange organization, Bob can do a free/busy query for Alice, but Joe from Google can’t currently.  However, in the basic authentication scenario, we will be providing the Exchange role account credentials to Google.  In that way, when Joe at Google wants to get free/busy information for Alice, Google “logs in” as the role account and gets the free/busy information for Alice, just like Bob could within the Exchange organization.  I tested both basic authentication as well as OAuth 2.0 so we’ll go over both.  First though, basic authentication.

I created an account with a mailbox: GSuiteFreeBusy@gwtoexo.ml

For production use, you want to ensure this accounts password does not expire after 30 days, etc. Also, if MFA is turned on, you’ll need an exception for this account if using basic authentication.

Now we can jump to Step 5 as we’re not doing the OAuth 2.0 part right now.  Sign in to your Google Admin console: https://admin.google.com/ as your admin account that has Super Admin permissions.

Click on Apps -> Google Workspace -> Calendar and then click Calendar Interop management.

 Check the box here to Enable Interoperability for Calendar and select Exchange Web Services (EWS) under Type as I show below:

If you’re using Office 365 Exchange Online, you’ll enter the following for the Exchange Web Services URL: https://outlook.office365.com/EWS/Exchange.asmx

You’ll enter the Exchange Role Account email address and then as we are testing Basic Authentication first, ensure that option is selected and click on Enter Password and enter the password for this account. Once you did that it should look like this:

You then have the option to select Show Event Details to get more info or an option regarding Room booking, but for just basic information, leave these unchecked and click SAVE.

In the second part “Allow Exchange users to see Calendar availability data”, we create the Google role account and generate some PowerShell code which we’ll run in the Exchange environment to add the availability space.  Yes, having Google generate PowerShell code that runs in your Microsoft environment is unsettling…. I understand, but we must continue on…

There are five steps listed here, we can skip steps 1 and 2 because I’ve already setup the Google Workspace users and there are no concerns about Internet connectivity.  One note on step 1 though, on the Exchange side it’s OK to use a Mail-Enabled User vs a mail contact.  It will work in the same way.

In Step 3, we create the Google Role account.  This is the account that Exchange will use to act as a proxy to retrieve free/busy times for the users on the Google side.  This should be a regular low-privileged account with Calendar enabled.

Open the following link and click Execute for the Exchange authentication credential generation tool: https://calendar.google.com/Exchange/tools/ while logged in as your super administrator account.

Check the box to acknowledge “I understand that regenerating these credentials will revoke any old credentials for the Google Role Account” and click Generate new credentials.

At this point, you will be prompted to sign in as the Google role account to generate this new credential. Worth mentioning again, sign in as the Google Role account!

After hitting Next and signing in, you’ll need to click Accept on the Terms of Service.

You’ll then click Download and save this credentials.dat file in a safe place (you only get this one shot to download them.)

The credentials.dat file is just a simple file that looks like this:

Now we move onto Step 4 which will ultimately add the availability address space to Exchange.

While still logged in as your super administrator account, go back to this page: Google Calendar: Calendar Interop Tools and click Execute on the Exchange Server configuration.

You’ll end up on this screen where you will click Choose File and navigate to and upload the credentials.dat file that you saved earlier.  Also, make sure Exchange 2013 or newer, including Office 365 is selected.

Enter the email address of the Exchange role account that Google will use to contact the Exchange environment and the Google availability address space and then click Show Exchange setupNote: In my testing I used a domain alias gsuite.acquired.ml as the availability address space as I was doing some other different testing as well, but if your G-Suite and Exchange don’t have overlapping email addresses, just use the main domain of the Google Workspace, in this case it would have been just acquired.ml.

The Google tool now shows the following configuration information as well as the PowerShell code snippet to run in the Exchange environment.

You’ll want to copy and paste this code shown into an Exchange PowerShell window logged in with the correct Exchange permissions to add the availability address space.

Now we move onto Step 5 where we wait or restart our Exchange Server.  For fun, create a ticket with Microsoft to restart the Exchange Online worldwide… just kidding, give it a little time and it will be fine.

We can now move to the last step which is “Verifying the user availability setup.”

Here I recommend using the Google Availability Lookup Tester located at the same page as we used before: Google Calendar: Calendar Interop Tools

The first time I ran the availability lookup tester tool, I got this error:

This is basically saying that Google couldn’t reach the Exchange server.  Why?  Because with new tenants, Microsoft enables “Security Defaults”.  So I could complete my testing, I disabled this, but more information from Microsoft about this is located here: Disable Basic authentication in Exchange Online | Microsoft Docs  Make sure you understand the consequences of doing this.

Now when I test, I got a successful result.

The real testing though is from the end users perspective, so let’s take a look.

Here, Bob Smith who has a mailbox in Exchange makes a calendar entry in his Outlook:

Bob Slydell who has a mailbox in Google Workspace can see that Bob Smith is busy from 9:30 to 11PM.  It only shows Busy since we elected not to share event details during the setup.

Bob Smith creates some more meetings in his Outlook calendar:

Bob Slydell in G-Suite again has no problem seeing that Bob Smith is busy:

Now let’s look in the other direction.  Bob Slydell has some calendar entries in his Google calendar:

When Bob Smith who is on Exchange uses the Scheduling Assistant to query free/busy times for Bob Slydell, he sees the following (Note: it works for bob.slydell@gsuite.acquired.ml and not bob.slydell@acquired.ml.  This is because how I set the Google availability address space.  With non-overlapping domains use the main domain for the Google availability address space, i.e. acquired.ml):

Here you can see Bob Slydell’s Google calendar that shows the event details, i.e. at 9am where Bob Smith is looking it shows “Don’t call me” vs just Busy which appears to Bob Smith.

I’ll be adding to this blog post at a later time to show how this can also be setup using OAuth2 vs basic authentication and explaining the pro’s and con’s of each approach.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s