Resolving sync errors.

Where sync errors show up

When you click Sync now on a domain, or when a scheduled sync runs, TenLens records the result for each object type. You see sync results in two places:

• The Sync activity card on the dashboard, where each run is grouped by object type (Users, Groups, Computers, Organizational Units, Contacts, GPO links).
• The per-domain Sync panel, which shows the last run, the object counts, and any error message for a failed type.

A failed type shows a short error message. The sections below map the common Active Directory messages to a cause and a fix.

Server does not support the control

This is the most common Active Directory sync error, and it is almost always caused by an out-of-date collector.

To read large object types efficiently, TenLens asks the directory for results one page at a time using the standard LDAP paged-results control (OID 1.2.840.113556.1.4.319). Paging is an LDAP version 3 feature. An older collector could open its directory connection as LDAP version 2, on which Active Directory cannot honor the paging control. Because TenLens marks that control as required, the domain controller rejects the request instead of silently returning an unpaged result, and you see the error above.

Smaller object types (and the initial connection checks) do not request paging, which is why connection health and some object types can stay green while a large type fails.

1. 1
   Update the collector

   Install the latest TenLens Collector on the collector host. Current collector builds always negotiate LDAP version 3, so the paging control is accepted and large object types sync normally. This is the fix for this error.

2. 2
   Confirm the directory advertises paging (optional)

   Paged results is supported by every supported version of Active Directory, so this rarely needs checking. If you want to confirm on a domain controller, run an elevated PowerShell session and look for the paging OID in the root of the directory:

   POWERSHELLCopy

   $root = [ADSI]"LDAP://RootDSE"
   $root.supportedControl -contains "1.2.840.113556.1.4.319"

   A result of True confirms the domain controller supports paging. If it is True but a sync still fails with this error, the collector is the out-of-date component; complete step 1.

3. 3
   Re-run the sync

   After the collector is updated, click Sync now on the domain. The previously failed object types should complete and report their object counts.

Read account cannot bind during sync

The directory sync uses the same domain read account as the connection checks. If the bind fails at sync time, treat it like a read-account problem:

• Confirm the read account password has not expired or changed.
• Confirm the collector can still reach a domain controller. By default TenLens uses integrated authentication (an encrypted Kerberos/NTLM bind) over TCP 389, which needs no certificate on the domain controller. If you chose Simple bind over LDAPS in the wizard, the collector instead needs TCP 636 and a valid LDAPS certificate.
• Confirm the target domain controller is running.

See Connecting Active Directory for the full read-account checklist, then click Sync now again.

A sync finishes with fewer objects than expected

Active Directory returns very large multi-valued attributes (such as group member lists) in ranges, and very large result sets in pages. Current collectors handle both. If counts look low:

• Make sure the collector is current (the same update that resolves the control error above also enables full paged reads).
• Allow the sync to finish; large domains can take several minutes per object type on the first full sync.
• Re-run Sync now and compare counts across two consecutive runs. Stable counts across runs indicate the sync is complete, not truncated.

How incremental sync works

After the first full sync, TenLens keeps each domain up to date by pulling only what changed since the previous run, using the directory's built-in replication (DirSync). New and modified objects are refreshed, and objects deleted in Active Directory are marked deleted in TenLens automatically. This keeps scheduled syncs fast on large domains.

Incremental sync needs the read account to hold the Replicating Directory Changes right on the domain:

• With the right: scheduled runs pull deltas only, so they finish quickly.
• Without the right: TenLens detects this automatically and falls back to a full read every run. Nothing fails and no data is missed; runs simply take longer on large domains. To enable efficient deltas, grant the read account Replicating Directory Changes (delegate it on the domain in Active Directory Users and Computers, or via dsacls) and the next run switches to incremental on its own.

Still stuck?

A quick checklist for Active Directory sync problems:

• The collector is running the latest build (resolves the paged-results control error).
• The read account can bind (green connection health, correct password, reachable domain controller).
• The sync has been allowed to finish on large domains, and counts are stable across two runs.

If problems persist, open the Desktop Launcher Support tab and submit a ticket with Attach diagnostics bundle enabled so the collector and sync logs are included.