Use logs to troubleshoot

Occasionally, you'll get lines in Password Sync logs that seem like errors. Often, these don't actually indicate any issue with the sync or with the setup. Use the information below to troubleshoot. 

Try the Log Analyzer

Submit your trace logs to the Google Admin Toolbox Log Analyzer. Most issues can be identified within a few moments of submission.

Get details on where to find your trace log files.

Password Sync logs

Expand section  |  Collapse all & go to top

Where are the trace file logs located?

You can find Password Sync trace logs on your computer at this location: C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Google\Google Apps Password Sync\Tracing\password_sync_service

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

Where are the other logs & configuration files located?

You can use the Password Sync Support Tool (an open-source tool by Google) to gather Password Sync logs and troubleshooting information from all of your domain controllers.

Find configuration files and logs

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 Password Sync 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:

    C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Google\Identity

  • 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 Password Sync 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:

    C:\Users\your-user-name\AppData\Local\Google\Identity

  • 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 Password Sync.

Crash reports logs

  • Location of file:

    If the Password Sync UI configuration tool crashes, the logs can be found here:
    C:\Users\your-user-name\AppData\Local\Temp

    If the Password Sync 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 Password Sync configuration wizard crashes:

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

If the Password Sync service crashes:

  1. Download the PsExec program file from this Microsoft article.
  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

[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://www.fiddler2.com
DO_NOT_TRUST
*.google.com
---Issuer----
Created by http://www.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.

Log errors

Expand section  |  Collapse all & go to top

Errors at the top of the logs mentioning Outlook

If you're using an older version of Password Sync, it might display errors related to Microsoft Outlook at the start of the log files. This does not affect Password Sync, you can ignore these errors. Here’s an example of a Password Sync log with Outlook errors:

2022-04-12T09:00:00.563+03:00 14cc E:Generic password_sync_service!GetOutlookExePath @ 24 ()> Failed with 0x80070002, last successful line = 17.
2022-04-12T09:00:00.578+03:00 14cc E:Generic password_sync_service!GetOutlookVersion @ 255 ()> Failed with 0x80070002, last successful line = 247.
2022-04-12T09:00:00.578+03:00 14cc E:Generic password_sync_service!GetOfficeRegistryBase @ 362 ()> Failed with 0x80070002, last successful line = 360.
2022-04-12T09:00:00.578+03:00 14cc E:Generic password_sync_service!ResourceStrings::GetOutlookLanguage @ 124 ()> Failed with 0x80070002, last successful line = 111.

The Password Sync logging component is trying to find the Outlook version to report it in the logs. Since Password Sync doesn't require Outlook, you can safely ignore these errors.

WinHTTP warnings & errors in the service logs

Some errors and warnings that relate to WinHTTP (the Microsoft Windows component Password Sync uses to connect to Google) are benign, for example:

2022-08-06T03:30:46.590-07:00 8d4 W:Network password_sync_service!LogPotentialProxyNetworkFailure @ 287 (user@example.com)> WinHttpGetProxyForUrl auto-detect failed with 0x80072f94. 0/(null). IsNetworkActive is 1, flags 1, IsNetworkActive GetLastError 0x80004005
2022-08-06T03:30:47.371-07:00 8d4 A:PasswordSync password_sync_service!PasswordSyncTask::RetriveUser @ 210 (user@example.com)> retrieved user......
2022-08-06T03:30:47.374-07:00 8d4 A:PasswordSync password_sync_service!PasswordSyncTask::RetriveUser @ 257 (user@example.com)> Successfully retrieved user
2022-08-06T03:30:47.374-07:00 8d4 A:PasswordSync password_sync_service!AppsLogin::AppsLogin @ 32 (user@example.com)> Created Apps login
2022-08-06T03:30:48.113-07:00 8d4 A:PasswordSync password_sync_service!PasswordSyncTask::UpdateUser @ 181 (user@example.com)> Successfully updated password
2022-08-06T03:30:48.113-07:00 8d4 W:Network password_sync_service!WinHttp::WaitForAsyncEvent @ 2088 (user@example.com)> Handle closed while waiting for CloseAllTrackedWinhttpHandles.
2022-08-06T03:30:48.113-07:00 8d4 E:Network password_sync_service!WinHttp::WaitForAsyncEvent @ 2089 (user@example.com)> Failed with 0x80072ef3, last successful line = 2062.
2022-08-06T03:30:48.113-07:00 8d4 E:Network password_sync_service!WinHttp::CloseAllTrackedWinhttpHandles @ 1766 (user@example.com)> Failed waiting for handle close, retry 0, hr = 80072ef3, 1 handles remaining

The errors and warnings indicate some actions didn't complete as Password Sync expected. However, the logs report "Successfully updated password". This indicates you can ignore the network-related errors and warnings because the password was synced correctly.

Failure to read some data from Active Directory in the service logs

You might get errors such as these in the logs:

2022-04-25T14:24:54.052+03:00 fd0 A:PasswordSync password_sync_service!PasswordSyncService::RunSyncService @ 309 ()> Updating password for "COMP$"

2022-04-25T14:24:54.130+03:00 93c E:PasswordSync password_sync_service!LDAPConnector::QueryForTargetEmail @ 86 ()> Failed with 0x80005010, last successful line = 83.

2022-04-25T14:24:54.130+03:00 93c E:PasswordSync password_sync_service!PasswordSyncTask::DoWork @ 77 ()> Error while retrieving target email for COMP$

The entity whose password is being updated ends with a dollar sign ($). This indicates it's a computer account in Active Directory. Since computer accounts don't have email addresses, Password Sync couldn't retrieve the email address and therefore didn't sync the password. This is expected because Windows automatically sets the computer accounts' passwords and they don't need to be synced to your Google Account.

Errors loading data in the configuration interface logs

When running the Password Sync configuration interface for the first time, you might get these errors (marked with the label "E:") in the Password Sync config UI logs:

2022-02-13T16:07:05.374+00:00 13e0 A:PasswordSync PasswordSync!PasswordSyncConfig::InitSyncConfig @ 334 ()> Loading config from C:\ProgramData\\Google\Google Apps Password Sync\config.xml
2022-02-13T16:07:05.374+00:00 13e0 E:PasswordSync PasswordSync!SyncConfig::Load @ 40 ()> Failed with 0x80070002, last successful line = 37.

This is expected because you're running the configuration interface for the first time, no configuration exists. However, if this is in the service logs, it might indicate you've turned on application compatibility for Password Sync. Make sure it's turned off before trying to set up Password Sync again.

Common Windows event log entries created by Password Sync

Password Sync adds Windows event log entries for key events. You can find them under Event Viewerand thenApplications and Services Logsand thenGoogle. All events have "GoogleAppsPasswordSync" as the source. These messages are also written to the Password Sync log files.

Note: Windows event log entries are informational to allow for easy monitoring. For full troubleshooting information, go to Troubleshoot Password Sync.


If a password sync is unsuccessful because it doesn't meet the username and group name guidelines or password guidelines:

Event ID: 258
Severity: Warning
Category: LSASS
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 the Google Account, and will be out of sync with Active Directory.

 


If the Password Sync Service is down while users try to change their password:

Event ID: 259
Severity: Error
Category: LSASS
Contents: An error occurred while trying to communicate with the Password Sync Service; the password update request for account "USERNAME" could not be processed.

Status = 0 (0x00000000).

Please make sure the service is running.


If an error occurs while hashing a password for a user:

Event ID: 260
Severity: Error
Category: LSASS
Contents: An error occurred while hashing the password for account "USERNAME".

Status = 0 (0x00000000).


If a user sets a password longer than 200 characters, it gets truncated. The password set by the user in Active Directory remains intact, but it will be out of sync with the Google Account:

Event ID: 261
Severity: Warning
Category: LSASS
Contents: Password for account "USERNAME" being trucated to to the first 200 characters.


When the Password Sync service is started:

Event ID: 512
Severity: Informational
Category: Service
Contents: Password Sync service starting.


When the Password Sync service is stopped:

Event ID: 513
Severity: Informational
Category: Service
Contents: Password Sync service shut down.

Status = 0 (0x00000000)


When an Active Directory user password is successfully synchronized with a Google Account:

Event ID: 514
Severity: Success
Category: Service
Contents: The password change for Active Directory user "USERNAME" was synchronized to Google Account "username@example.com" successfully.

Status = 0 (0x00000000)


If Password Sync receives a password change notification and it can't find the corresponding Active Directory user:

Event ID: 768
Severity: Error
Category: LDAP Connector
Contents: The account "USERNAME" was not found on Active Directory.

LDAP Connector status = 20498 (0x00005012).

Note: For more information, go to error code 0x00005012.


If an Active Directory user without an email attribute set changes their password:

Event ID: 769
Severity: Warning
Category: LDAP Connector
Contents: The account "USERNAME" seems not to have an Email attribute set; its password will not get synchronized to Google.

LDAP Connector status = -2147463152 (0x80005010).

Note: For more information, go to error code 0x80005010.


If unexpected errors occur while querying Active Directory:

Event ID: 770
Severity: Error
Category: LDAP Connector
Contents: An unexpected error occurred while querying Active Directory.

LDAP Connector status = -2147467259 (0x80004005).

System Message: Unspecified failure


If an API request is unsuccessful when trying to sync a password:

Event ID: 1024
Severity: Error
Category: Google Connector
Contents: An API call to the Google server returned an unexpected response while updating the password for account "username@example.com" during the 'PasswordSyncTask::PutUser' step; all retries have been exhausted.

Details:
- Host: apps-apis.google.com
- Auth Result = 0 (0x00000000)
- GDataStatus = 7 (0x00000007) GDSTATUS_BAD_REQUEST
- hResult 1 = -2147217401 (0x80041007)
- hResult 2 = 0 (0x00000000)

Note: The event details might include different status and result codes, and further inspection of the Password Sync log files might be necessary to accurately identify the cause of the error.


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?
Search
Clear search
Close search
Google apps
Main menu