Troubleshooting GSPS

G Suite Password Sync

If you're experiencing issues with setting up G Suite Password Sync (GSPS), review these solutions to common issues with GSPS.

Before you begin

Before you begin troubleshooting, make sure that:

  • You meet all the system requirements and your domain controllers are set up correctly. Learn more
  • You’ve completed every setup step. Learn more

If you continue to experience issues, check below for solutions to common GSPS issues.

Common GSPS issues

Open all   |   Close all

GSPS is synchronizing passwords for some, but not all, of my users

If some users' passwords aren't synchronized, make sure that:

  • You have installed GSPS successfully on all of your domain's Microsoft Active Directory servers (domain controllers). On Microsoft Windows Server 2008 and above, you only need to install GSPS on writable domain controllers. If you're not sure, install GSPS on all of your domain controllers. Doing so won't cause any issues.
  • The account privileges for the user whose update was unsuccessful doesn't exceed those of your admin account. User accounts with fewer privileges can't change passwords on accounts with more privileges. For example, an account with admin privileges can't update passwords for accounts with super-admin privileges.
  • Your users have email addresses in the attribute you specified under Mail Attribute during configuration. These addresses must match their Google primary email addresses exactly (including the domain part of the address).
  • The password meets the username and group name guidelines. If a password doesn't sync because it contains unsupported characters, GSPS logs a warning to the Windows Application event log. For example:

    Log Name: Application
    Source: G Suite Password Sync
    Event ID: 40963
    Level: Warning
    Contents: An attempt to change the password for user USERNAME was made. However, the new password contains unsupported characters. The password can not be updated on G Suite, and will be out of sync with Active Directory.

I'm an Active Directory administrator, but I'm not authorized to install or set up GSPS

To install GSPS, you must be a member of the Domain Admins group. Being a member of the Administrators group does not provide sufficient authorization.

You must sign in to Windows as a domain admin in the same domain as the domain controller you’re setting up. If you sign in as a domain admin from a different domain (such as an Enterprise Admin from another domain, or an admin from a trusted domain) you won't be authorized to install or configure GSPS.

The GSPS installer was unsuccessful

Check that your setup:

  • Is running the installer locally (not over a network)
  • Has the right version of GSPS for your server's architecture (32-bit or 64-bit)
I'm unable to grant access to GSPS

Make sure you have granted app access control to G Suite services. Learn more

I need help with configuring proxy settings for GSPS

GSPS supports proxy connections if you set up system-wide proxy settings on all of your domain controllers:

  1. Make sure the current user's proxy settings are set up correctly by navigating to in Microsoft Internet Explorer.

    If you're redirected to a page or a page saying "Not Found," your proxy settings are probably correct. If there’s an authentication prompt or certificate error, your proxy settings might not be correct.

  2. Execute the following command in the command prompt: netsh winhttp import proxy ie.
  3. (Optional) If you aren't using a proxy server, but are still encountering proxy-related issues, run the command bitsadmin /util /setieproxy networkservice no_proxy in the command prompt. This command sets Windows to ignore any autodiscovered proxy configuration that might be present in the system.


  • GSPS supports unauthenticated proxies only. If your proxy requires authentication (Basic, Kerberos, or NTLM), you need to configure it to allow unauthenticated or direct connections from your domain controllers to the connections specified in Set up your domain controllers.
  • Although GSPS supports proxy connections, you might need to turn on a direct connection to make sure the proxy server doesn't cause issues. Because a proxy configuration depends on your local setup, Google Cloud Support cannot assist you with configuration issues. Contact your network administrator if you encounter any proxy issues.
I get a "Network error connecting to Google" error when attempting to authorize

This error indicates GSPS couldn't verify your authorization. Check your proxy settings and make sure your network allows connections to the URLs required by GSPS.

After installing new GSPS servers, my existing servers display authorization errors

There’s currently a token limit per user account per client when using 3-legged OAuth to authenticate your Google domain. If the limit is reached, creating a token automatically invalidates the oldest token without warning. Learn more

To avoid token limits, you should use a service account, rather than 3-legged OAuth. For details, go to Choose your Google authentication method.

Automatic troubleshooting

You can use the third-party GSPS support tool to gather GSPS logs and troubleshooting information from all domain controllers. It connects to the writeable domain controllers in your domain and gathers the information listed in the troubleshooting checklist below (except for network connectivity tests).

Manual troubleshooting checklist
Some of the steps in this list require running console commands.

Open a Command Prompt (CMD)

  1. In the Start menu, click Windows Systemand thenCommand Prompt.
  2. (Optional) Depending on your system, you might need to right-click Command Prompt and click Moreand thenRun as administrator.

First, complete these steps

  • Make sure you're a member of the Domain Admins group.
  • List your domain controllers. To do so, run the command nltest /, replacing with the name of your Active Directory domain.

Complete these steps on each domain controller

  1. Make sure the correct version of GSPS (32-bit or 64-bit) is installed on the server.
  2. Restart the server after installing GSPS.
  3. Check you can access using Internet Explorer. It's OK if this page shows a Google error or displays "Not Found." Make sure the page doesn't show a certificate error or any requests for proxy authentication. Authenticated proxy servers are not supported.
  4. Copy your current user's proxy settings to the system-wide proxy settings by running the command: netsh winhttp import proxy ie
  5. If you aren't using a proxy server, but are encountering proxy-related issues, run the command: bitsadmin /util /setieproxy networkservice no_proxy
  6. Check the GSPS DLL is registered on the machine by running the command: reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Notification Packages"

    The output should include the text password_sync_dll. If it doesn't, reinstall GSPS.

  7. Verify the GSPS DLL is loaded by running the command: tasklist /m password_sync_dll.dll

    The process "lsass.exe" should be listed in the results. If it isn't listed, the DLL isn't loaded. Verify the DLL is registered and the edition (32-bit or 64-bit) matches the system. Then, restart the machine so the DLL loads.

  8. Check the GSPS service has started by running the command: sc query "G Suite Password Sync" (or sc query "Google Apps Password Sync", if you’re using version 1.6 or earlier).

    If the output says:

    • STATE: RUNNING—The service is running.
    • STATE: STOPPED—The service isn't running.

      Run the command: sc start "G Suite Password Sync" (or sc start "Google Apps Password Sync", if you’re using version 1.6 or earlier).

    • The specified service does not exist as an installed service—The service isn't installed.

      Complete the steps in Set up G Suite Password Sync. The summary screen of the configuration tool should now confirm the service is running.

  9. Make sure your network and proxy settings are set up correctly. Learn more
Where are the logs and configuration files located?

You can use the GSPS support tool to gather GSPS logs and troubleshooting information from all of your domain controllers.

To manually find these logs, use the following information:

Configuration file

  • Location of file:

    C:\ProgramData\Google\Google Apps Password Sync\config.xml

  • What to do with the file:

    Review this file to inspect your settings.

Service logs

  • Location of file:

    C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Google\Google Apps Password Sync\Tracing\password_sync_service

  • What to do with the file:

    Review these files if GSPS was set up successfully but all or some of your users' passwords are not being synced.

    To view an example of a trace log file, go to check the logs below.

Service authorization logs

  • Location of file:


  • What to do with the file:

    Review these files if there are "Authentication failed" errors with error codes 0x6, 0x203, 0x4, or 0x102 in the GSPS service logs.

    To view an example of an authorization log file, go to check the logs below.

Configuration interface logs

  • Location of file:

    C:\Users\your-user-name\AppData\Local\Google\Google Apps Password Sync\Tracing\Password Sync

    C:\Users\your-user-name\AppData\Local\Google\Google Apps Password Sync\Tracing\GoogleAppsPasswordSync (if you're using version 1.6 or earlier)

  • What to do with the file:

    Review these files if you encounter issues during the configuration.

    To view an example of a trace log file, go to check the logs below.

Configuration interface authorization logs

  • Location of file:


  • What to do with the file: 

    Review these files if you encounter issues during the Google authorization part of the configuration.

DLL logs

  • Location of file: 

    C:\Windows\System32\config\systemprofile\AppData\Local\Google\Google Apps Password Sync\Tracing\lsass

  • What to do with the file: 

    Review these files if the service logs show no indication of password change attempts (no success and no issue reports).

Command-line installer logs

  • Location of file: 

    C:\Users\your-user-name\AppData\Local\Google\Google Apps Password Sync\Tracing\MsiExec

  • What to do with the file: 

    Review the installer logs and the msi_log.txt file (or the filename supplied to parameter /l*vx), if you encounter issues during a command-line installation of GSPS.

Crash reports logs

  • Location of file:

    If the GSPS UI configuration tool crashes, the logs can be found here:

    If the GSPS service crashes, the logs can be found here: C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp

  • What to do with the file: 

    If the administrator has changed the default temporary directory, go to How to identify your temporary directory for instructions on getting this information.

How to identify your temporary directory

If the GSPS configuration wizard crashes:

  1. Open a Command Prompt (CMD)
  2. Enter: echo %TEMP%

If the GSPS service crashes:

  1. Download the PsExec program file from Microsoft.
  2. Open a Command Prompt (CMD).
  3. Go to the directory where the PsExec file was downloaded.
  4. Enter: psexec.exe -i -s %SystemRoot%\system32\cmd.exe
  5. A new command window opens. Specify the command: whoami.

    It should display a message like "nt authority\system".

  6. Enter echo %TEMP%
Check the logs

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

[] TLS connection failure. See details below. [Status: 0x00010000. Status Info: 0x00000001]
[] Certificate details:
Valid from: 2017-09-13 17:23:55 UTC
Valid until: 2017-12-06 17:10:00 UTC
Mountain View
Google Inc
Google Inc
Google Internet Authority G2
[] 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.
[] Error from API WinHttpSendRequest with WinHTTP proxy. Will try direct (without proxy). Code: 0x00002f8f
[] Network connection destination details: (

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 address, meaning it's Google.

Trace log example

Note: This log example is from GWMMO. Similar trace log entries will also appear in GWMME, G Suite Password Sync (GSPS), 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:
Valid from: 2016-09-20T04:08:45.000Z
Valid until: 2022-09-20T04:08:45.000Z
Created by
Created by
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: (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 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.

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?

Need more help?

Sign in for additional support options to quickly solve your issue