Network traffic issues

Google Workspace Sync for Microsoft Outlook

If you're having network-connectivity issues with Google Workspace Sync for Microsoft Outlook (GWSMO), here are some steps that can help you fix the problem.

Fix connectivity issues

Expand all | Collapse all

Step 1: Open network ports

Open port 443 for Outlook.exe and ProfileEditor.exe. Our synchronization products communicate mostly on network port 443 so this action can resolve many issues. For details on Microsoft Windows Defender Firewall, consult this Microsoft article. Otherwise, check your firewall's documentation.
Reinstall GWSMO from its download page to ensure the installation files download correctly.
Open port 80 to download the Certificate Revocation Lists (CRL).
Open ports 80 and 443 on Microsoft Windows firewall to allow Outlook to communicate with Google's servers. For details on Microsoft Windows Defender Firewall, consult this Microsoft article

Step 2: Allow traffic from permitted URLs

Approve the following URLs:

URL	Purpose
https://oauth2.googleapis.com/token https://googleapis.com/oauth2/v4/token	Authentication
https://googleapis.com/calendar/	Calendar
http://crl.pki.goog http://crls.pki.goog http://ocsp.pki.goog	Certificate Revocation Lists
https://google.com/m8/feeds/contacts/	Contacts
https://google.com/m8/feeds/gal	Global Address Book
https://mail.google.com/mail/r/ https://googleapis.com/gmail/	Mail
https://googleapis.com/drive/	Notes
https://googleapis.com/tasks/	Tasks

Note: If you're using a Windows parental control system, you might need to add URLs to your allowlist. For details, consult this Microsoft article.

Review how to find Google IP address ranges. GWSMO can use any one of these IP addresses.

For details on current CRLs, go to CRL check.

Step 3: Check if you're using a proxy

GWSMO doesn't support authenticated proxies. Google Workspace Support doesn't offer assistance with connection issues if you're using a proxy.

To detect if you have a proxy:

Close all Microsoft Internet Explorer windows.
Open a new Internet Explorer window.
Go to https://mail.google.com.
If you're prompted for proxy authentication, contact your network administrator for help.

To check WinHTTP proxy settings:

Open a command prompt.
To check the proxy settings, enter the following command:
netsh winhttp show proxy

Step 4: Consult the log files

Network problems are logged in GWSMO's trace files. Submit your trace logs to the Google Admin Toolbox Log Analyzer. Most issues can be identified within a few moments of submission. Learn more

Troubleshoot common issues

Check the logs for network or TLS issues

If you have network errors (for example, a network timeout, connection refused, etc.) or SSL/TLS issues (for example, a secure connection problem), the logs show the IP address the tool tried to connect to. If there's a secure connection issue, the logs show the reason (for example, certificate name mismatch, certificate expired, CRL check was unsuccessful, etc.) and the certificate details (for example, a Google certificate or a HTTPS-inspecting proxy). This should significantly reduce the need to get network captures for troubleshooting, and applies to both the main logs (Trace-*.log) and the authorization logs (in the "Identity" folder).

Authorization log example

[2022-09-21T03:59:46:ERROR:windows_http.cc(331)] TLS connection failure. See details below. [Status: 0x00010000. Status Info: 0x00000001]

  [2022-09-21T03:59:46:ERROR:windows_http.cc(340)] Certificate details:

  ---Validity--

  Valid from: 2017-09-13 17:23:55 UTC

  Valid until: 2017-12-06 17:10:00 UTC

  ---Subject---

  US

  California

  Mountain View

  Google Inc

  *.googleapis.com

  ---Issuer----

  US

  Google Inc

  Google Internet Authority G2

  -------------

  [2022-09-21T03:59:46:ERROR:windows_http.cc(282)] WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED: Certification revocation checking has been enabled, but the revocation check failed to verify whether a certificate has been revoked. The server used to check for revocation might be unreachable.

  [2022-09-21T03:59:46:ERROR:windows_http.cc(197)] Error from API WinHttpSendRequest with WinHTTP proxy. Will try direct (without proxy). Code: 0x00002f8f

  [2022-09-21T03:59:46:ERROR:windows_http.cc(107)] Network connection destination details: 216.58.194.170:443 (sfo07s13-in-f170.1e100.net)

In this case, the year in the machine's current date was changed to 2022, making the certificate seem out of date. You can view the current date at the start of each log line, and the "Valid from" and "Valid until" dates of the certificate don't match the current date. The error flag WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED indicates the certificate revocation check was unsuccessful.

You can also view the destination IP address and the resolved hostname after "Network connection destination details" on the last log line. It's a 1e100.net address, meaning it's Google.

Trace log example

Note: This log example is from GWMMO. Similar trace log entries will also appear in GWMME, Password Sync, or GWSMO when these products experience network/TLS issues.

2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2025 ()> Secure connection failure. Status: 0x00010000. Info 0x00000009 2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2030 ()> Failure details: WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED: Certification revocation checking has been enabled, but the revocation check failed to verify whether a certificate has been revoked. The server used to check for revocation might be unreachable. WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA: The function is unfamiliar with the Certificate Authority that generated the server's certificate. Certificate details: ---Validity-- Valid from: 2016-09-20T04:08:45.000Z Valid until: 2022-09-20T04:08:45.000Z ---Subject--- Created by http://fiddler2.com DO_NOT_TRUST *.google.com ---Issuer---- Created by http://fiddler2.com DO_NOT_TRUST DO_NOT_TRUST_FiddlerRoot ------------- 2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2071 ()> Error result 5, hr = 0x80072f8f. Setting event 0000000000001638. 2017-09-21T04:10:04.356-03:00 1a20 E:Network ClientMigration!WinHttp::HandleCallback @ 2076 ()> Network connection destination details: 127.0.0.1:8888 (COMPUTERNAME)

In this case, Fiddler was installed and set to do HTTPS decryption (meaning it uses its own certificate), but its certificate was removed from the Windows trusted certificate list, so it's untrusted. Note that because Fiddler is a proxy, it was connecting to 127.0.0.1 and not to Google. The error flags include WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA, which means the system doesn't trust the Certificate Authority (CA). Also notice Google did not issue this certificate.

The example text displayed here is easy to forge if you're an attacker, so it shouldn't ever be used for authentication (use a CA signature instead). However, it's useful for identifying setup issues with firewalls/proxies that do SSL inspection/man-in-the-middle (MITM) attacks.

Note: Older versions of GWSMO might not include the advanced logging features discussed here. We recommend you update to the latest version. For details, go to Step 1.

Important: Our support team is happy to provide these guidelines for setting up your network to work with GWSMO. However, we can't assist with your network configuration. For help, contact your local network administrator.

_{Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.}

Was this helpful?

How can we improve it?