PeopleSync Knowledge Base
PeopleSync Knowledge Base
Breadcrumbs

Contacts Not Syncing to iOS or Android Phones

For PeopleSync administrators troubleshooting missing or out-of-date contacts on iOS and Android.

Follow one affected contact from the source system to PeopleSync Console, then the frontend and phone. Compare a specific value, such as a phone number, allowing for the agent's field mapping. Finding the contact by name alone does not prove it is up to date.

Keep HTTPS and certificate checks enabled. Test with the affected user's account, not a service account.

Identify the scope

  • One phone or user, one platform, or everyone?

  • One address list, a few contacts, or all contacts?

  • Missing contacts or outdated details?

  • Did sync never work, or did it stop working? What changed?

  • When did the source data change, and when was the last successful sync?

Quick diagnostic path

What you find

Next step

Contact missing or outdated in Console after the expected agent run

1. Agent import

Console is current, but the user cannot access the list or contact through CardDAV

2. Publication and permissions. For login or connection errors, use step 3.

Connection or login fails, or CardDAV returns older data than Console

3. Frontend and network

A new CardDAV request returns current data, but the phone does not

4. Phone

1. Verify the agent import

  1. In Console, check System Status and Backend Log for errors. Confirm that the PeopleSync Service is running and both the agent and its address list are enabled.

  2. Check the agent's schedule and last completed run. If the source data was changed after the agent ran the last time, wait for the agent to run again or run it manually.

  3. If allowed by your operating procedures, run the agent manually. Wait for the final result and check contact counts and errors.

  4. Open Address Lists and preview the affected contact. Compare its values with the expected result of the source data and field mapping.

If the contact is still missing or outdated, check the source record, filter, mapping, and agent errors. Continue only when Console shows the expected values.

After the agent has imported the current contacts, you have to wait for the phone to sync the change or manually trigger an update on the phone.

2. Verify publication and permissions

  1. Open the address list. Confirm that it is enabled and Published CardDAV is set to Published.

  2. Under CardDAV Permissions, check that the user's group has Read permission. Keep agent-managed lists read-only for users.

  3. Check membership using the rules below. Allow for normal directory replication and membership-update delays.

Directory

Group membership

Login name

Active Directory

The assigned security group must exist and its sAMAccountName must be unique across the forest. Distribution lists do not work. Nested membership is supported.

UPN, such as user@example.com, or DOMAIN\sAMAccountName.

AD LDS

Direct membership in the user's memberOf attribute. Nested groups are not supported.

userPrincipalName

NetIQ eDirectory

Direct membership in the user's groupMembership attribute. Nested groups are not supported.

uid

Please note that permissions are cached by the frontend. Therefore, it may take up to 30 minutes for permission changes to become effective.

References:

3. Verify the frontend and network

  1. Test the public HTTPS URL from the phone's network. A successful test from the backend server alone does not confirm that phones can connect.

  2. Check that the certificate is trusted, unexpired, and matches the hostname. Check DNS, routing, proxy, firewall, load balancer, and IIS bindings for the configured port, usually TCP 443 or 8843.

  3. In Console, check Log → Frontend Log and Login Failures at the failure time. Match the username and source IP. For login errors, follow the checks below before retrying.

  4. If the Console logs do not explain the error, check C:\Windows\Temp\php_peoplesync_errors.log at the same time.

When authentication fails

  1. Check Blocked Users if DoS protection is enabled. A block applies to a username/IP pair, so login from another network may still work. Look for “Too many authentication failures” or “Refusing access” in the Frontend Log.

  2. Check System Settings → Deny Authentication to Users without Permissions. When enabled, valid credentials can still receive HTTP 401 if the user has no address-list permission. Verify Read access and group membership before assuming the password is wrong.

  3. Check the password and the login-name format in the directory table above. Do not enable compatibility settings just for this test.

  4. After fixing the cause, wait for the block to expire or use Unlock user for that username/IP entry. Retest once and check the logs. Keep the configured security protections enabled.

More help:

Known iOS 18.4 login issue

If iOS 18.4 login fails and the frontend log shows %40 instead of @ in the username, check the installed versions. The fix requires Backend 24.11.13.1637 and Frontend 24.11.5 or newer.

Login Failure With iOS 18.4

4. Verify the phone

Use these checks when Console and a new CardDAV request both return current data but the phone does not. If the CardDAV check was not completed, device checks may still help, but the server's data remains unverified.

Common checks

  • Check the same server URL, user account, address list, contact, and field value used in the CardDAV test.

  • Run a manual sync. Record the time and any error, then compare the affected value again.

  • If a second approved client is available, compare its result. Note differences in network, app version, and managed settings; they may explain why only one device fails.

iOS

  1. Open the PeopleSync CardDAV account in iOS Settings. Check that the account and Contacts sync are enabled, with the correct HTTPS server and credentials.

  2. In Contacts, select the PeopleSync list and refresh it. Compare the affected value with the CardDAV result.

  3. For the specific iOS 18.4 login failure, see the version check above.

Android

  1. Open the PeopleSync CardDAV Client and confirm that the account exists. Android Enterprise users must open the app once to complete account creation.

  2. Check read and write Contacts permissions on the device and in its managed policy.

  3. Check the managed server URL, username, and proxy. If sync is restricted to certain Wi-Fi networks (SSIDs), connect to one of those networks.

  4. For SSID restrictions, also check the location permissions required by the installed app and Android version. The Android Enterprise Guide lists ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION. Confirm which are required and granted for your version.

  5. Check the scheduled sync interval: the documented minimum is 15 minutes. Manual sync does not require this wait. Changes to default_sync_interval apply only to new address-book accounts.

  6. Select the PeopleSync list in Contacts and compare the affected value after syncing.

More help: Android Enterprise Guide

Information to collect for escalation

  • How many users, phones, lists, and contacts are affected; Backend, Frontend, phone OS, and Android app versions.

  • Address-list name and agent type.

  • Source-change time and the times and results of the agent run, HTTPS test, CardDAV check, and phone sync.

  • Where the contact is missing or outdated: source, Console, CardDAV response, or phone. You do not need to include actual contact values.

  • Relevant error codes and short log excerpts with usernames, IP addresses, and customer details redacted.

Never send passwords, tokens, private keys, full vCards, directory exports, or unnecessary personal data.