Synced Contacts Report Up to Date but Never Change: the Source Domain Problem

Purpose

An attribute changes at the source — a phone number, a job title, a department — and the synchronized contact never reflects it. The policy reports success. The log says the contact is up to date. Nothing errors.

The signature that identifies this problem: deleting the contact and letting it be recreated brings it back fully current, while leaving it in place and waiting never updates it. Creation works; modification does not. If that describes what you are seeing, read on before changing anything else.

What is actually happening

Both products record, on every contact they create, the source domain the object came from. On subsequent runs, that stored value is how the product recognises a contact as one of its own and therefore one it may modify or delete.

If a contact's stored source domain is no longer part of the synchronization, the product will not modify it. It does not error, because nothing has gone wrong from its point of view — the contact simply is not in its remit. The run reports success and the log reports the contact as up to date, which is true in the narrow sense that the product has decided it is not going to touch it.

This is why the delete-and-recreate test works. A recreated contact carries the current source domain, so it is back in scope and updates normally from then on.

When a source domain changes underneath you

Nobody sets out to change a source domain. It happens as a side effect of changes people make for other reasons:

• A policy that once sourced from on-premises Active Directory is reconfigured to source from Exchange Online. Contacts created under the on-premises domain keep it.
• A migration, tenant consolidation or domain rename.
• An environment configuration rebuilt or replaced, where the new one presents a different source domain than the one the existing contacts were written with.
• A policy recreated from scratch rather than edited.

In every case the existing contacts are orphaned in place: visible, plausible, and permanently frozen at the values they had when the change happened.

The documented fix

contactSync provides an option for exactly this, and the manual prefaces it with "Please be careful with this option" — which is fair, because it widens what the policy is willing to modify and delete.

1. Find the old source domain in the log file. It must be entered exactly as it appears there — for example DC=forestB,DC=com. Do not reconstruct it from what you think the domain was.
2. Enable Modify or delete existing contacts with source domain in the policy.
3. Click Source Domain to open the Old Source Domains dialog, and add the old value to the list.
4. Run the policy and verify against a contact you know is stale.

Once the old domain is listed, contacts previously synchronized under it come back into scope and are modified and deleted normally.

Add only the specific old domains you have confirmed in the log. Every domain you add extends the policy's authority to delete contacts carrying it.

Two things that are often blamed and are usually not the cause

Missing property mappings. The natural first theory is that the changed attribute is not in the product's default property set, so the change is invisible to it. Test this before accepting it: if a newly created contact receives the same attribute correctly, the attribute is in the default set and missing mappings are not your explanation. This is a quick, decisive test and it rules out a whole line of investigation.

Address list configuration. A related theory attributes non-updating contacts to the address list selected in the import settings. That produces its own distinct errors and is worth checking on its own merits, but it does not produce the silent, no-error, reports-success behaviour described here.

A second cause that can coexist: contacts outside the policy's folder

Where contacts are synchronized into a named subfolder beneath the mailbox Contacts folder, check whether a legacy set also exists in the root Contacts folder.

Compare item counts between an affected mailbox and a recently created one. A new mailbox typically shows zero items in the root Contacts folder and the full synchronized set in the subfolder. A long-standing mailbox showing a large number of items in the root folder is carrying a legacy set that no current policy manages — frozen at whatever values it had when it was written.

This matters because of how clients display contacts. Mobile contact apps commonly merge cards across folders by display name, so the user sees one contact combining the current synchronized entry and the stale legacy one. The synchronized contact is correct; the merged view is not. Checking the server-side folder contents rather than the phone is the only way to see this clearly.

The two causes are not mutually exclusive and frequently appear together in environments that have been through a migration.

Removing a value rather than changing it

One behaviour to know before you try to reproduce a fix: a populated value is not overwritten with a blank just because the source value was cleared. Removing a phone number at the source does not remove it from the synchronized contact.

Clearing values requires an explicit find-and-replace property rule — find ^.*$, replace with nothing. Be aware that such a rule is policy-wide and unconditional: it clears that attribute for every object in scope, not for the one person whose number you wanted removed. It is not a targeted fix and should not be applied as one.

Verifying before and after

# What the source actually holds
Get-ADUser -Identity <user> -Properties telephoneNumber, mobile, ipPhone, otherTelephone, homePhone |
    Select-Object telephoneNumber, mobile, ipPhone, otherTelephone, homePhone

# What the synchronized contact holds
Get-Contact -Identity <user-address> | Select-Object *

Then run the decisive comparison: check the same attribute on a contact created after the change and on one created before it. A new contact carrying the correct value while an old one does not is the source-domain signature, and it points straight at the fix above.

References

• contactSync 8.7 Manual p.183 — Modify or delete existing contacts with source domain; the Old Source Domains dialog; the requirement to enter the old domain exactly as it appears in the log file.
• contactSync 8.7 Manual p.170 — find-and-replace property rules.
• The current manuals are published by NETsec at netsec.de.