Creating a contactSync Policy: the Decisions That Matter

Purpose

Setting up contactSync is three pieces of work in a fixed order: an environment configuration, an application registration, then the policy itself. The Quick Start Guide walks the clicks. This article covers the decisions inside those clicks — the ones that are awkward to change later, and the two that can lose users' own data.

What contactSync does

Worth stating precisely, because it is routinely confused with GALsync.

contactSync synchronizes contacts from a shared mailbox, a modern public folder, or the Global Address List into users' mailboxes in the same Exchange environment, writing them into a subfolder within the user's mailbox contacts. It works with on-premises Active Directory objects into on-premises mailboxes, and Microsoft 365 objects into Exchange Online mailboxes.

It cannot synchronize across tenants. If the source and the recipients are in different Microsoft 365 tenants, that is GALsync's job, and no contactSync configuration will achieve it. Establish this before designing anything — it is the single most common wasted effort in this area.

Order of work

1. Environment configuration — how contactSync connects to the Exchange environment.
2. App registration in Entra ID — certificate-based authentication, permissions, consent and the Exchange role.
3. Policy — the source, the recipients, the folder and the behaviour.

The second step is the one that takes the time and the one that fails most often. Get it working and verified before creating a policy, rather than debugging both at once. See Entra App Registration Permissions for GALsync and contactSync.

Create the certificate from within contactSync while logged on as the service account, because scheduled policies run as that account.

Decision 1: the source

Choose between the directory or GAL, a shared mailbox, or a modern public folder. This follows from where the authoritative list already lives — if a team already curates contacts in a shared mailbox, use it rather than rebuilding the same list as a directory scope.

Decision 2: who receives the contacts

Set on the Mailboxes tab. The options differ mainly in how well they survive people joining and leaving.

By group — recommended. contactSync resolves the group's members that have mailboxes during the policy run, so membership is always current without the policy being edited. Adding or removing a recipient later becomes a group membership change.

By organizational unit. Several scopes are available, all resolved at run time: Only this OU, Only Sub-OUs, OU + Sub-OUs, Include group memberships, and Include nested groups + memberships.

By Recipient Type — avoid. NETsec recommends migrating a Recipient Type selection to a dynamic distribution group. It also blocks something useful: in a hybrid environment, mailboxes can be selected from both Exchange on-premises and Exchange Online within the same policy only if no Recipient Type has been selected on the Mailboxes tab. If mailboxes are moving between the two, a Recipient Type selection will get in your way.

Decision 3: the contact folder — and the option that can lose data

This is where care is genuinely warranted.

Use a dedicated subfolder. The safe default: contactSync writes into its own named folder beneath the mailbox's Contacts folder, and users' personal contacts are untouched. Give the folder a name that will still make sense in three years, because renaming it later leaves an orphaned folder in every mailbox.

One policy per folder. Where several policies write into the same folder, each treats its contents as its own to reconcile and they delete each other's contacts.

If you do synchronize into the well-known Contacts folder, three options govern what happens to contacts contactSync did not create, and they differ sharply in risk:

• Do not touch untagged contacts — existing contacts are left alone unless contactSync created them.
• Synchronize an additional contact for each untagged contact — NETsec's recommendation where this is needed; a parallel contact is created alongside the existing one.
• Synchronize untagged contacts with contactSync — prefaced in the manual with "Please exercise extreme care with this option." Contacts your employees created below the folder can be synchronized and possibly deleted, causing them to lose information.

Choose deliberately. This is the setting to check first if users report losing their own contacts.

Decision 4: exclusions

Two custom-attribute marks, doing opposite jobs. Both go in extensionAttribute1–15 on-premises or customAttribute1–15 in Exchange Online:

• NoContactSync — the object is not synchronized as a contact. Use for someone who should not appear in other people's contacts.
• NoMailboxSync — the mailbox does not receive synchronized contacts. Use for someone who should not get the shared set.

For a whole category rather than individuals — unlicensed accounts, contractors, a site — a dynamic distribution group filter scales better than marking each object.

Decision 5: schedule

The contactSync Service exists only to run scheduled policies. It checks once a minute for policies due, queues them, and runs them sequentially as the account the service runs as.

Two consequences: a nightly run is usually sufficient for contact data, and everything the policy needs — PowerShell module, certificate — must be available to the service account, not just to you.

Before you go wide

1. Pilot against a handful of real mailboxes. Use a small recipient group first.
2. Check the result in a pilot mailbox on the server side, not only on a phone — mobile contact apps merge cards across folders by display name and will mislead you.
3. Run it a second time and confirm nothing is duplicated or removed. A single clean run proves creation works; the second proves reconciliation does.
4. Test a change at the source — alter an attribute and confirm it reaches the contact. This catches the source-domain problem early. See Synced Contacts Report Up to Date but Never Change.
5. Then expand the recipient group.

One thing to tell users

The contacts folder and its subfolders are not visible in the new Outlook. If people cannot see the contacts after a successful rollout, check which Outlook they are running before investigating anything else — classic Outlook displays them normally.

References

• contactSync 8.7 Quick Start Guide p.5 — what contactSync synchronizes and into where; the environment-then-policy sequence.
• contactSync 8.7 Manual p.113 and p.115 — the Mailboxes tab; group and OU selection scopes; hybrid selection when no Recipient Type is set; the NoMailboxSync mark.
• contactSync 8.7 Manual p.61 — the NoContactSync mark.
• contactSync 8.7 Manual p.163 — the well-known contact folder options and their warnings.
• contactSync 8.7 Manual p.59 — the contactSync Service; scheduled policies run in the service account's context.
• contactSync 8.7 Manual p.264 — the contact folder not visible in the new Outlook.
• The current contactSync manual and Quick Start Guide are published by NETsec at netsec.de.