How to Configure Selective Contact Synchronization Between Organizations

Purpose

After a merger or acquisition, the usual requirement is not "share everything with everyone". It is that a defined set of people in one organization should see the contacts of another, and often only in one direction. Both NETsec products support that kind of scoping — but which product you need is decided by something else entirely, and getting that wrong means designing a configuration that cannot work.

First decide which product applies

This is the question to answer before any policy is designed, because the answer is not about scoping at all — it is about how many Exchange environments are involved.

• contactSync synchronizes contacts within a single Exchange environment or tenant — from a shared mailbox, a modern public folder, or the directory — into a contacts subfolder in individual users' mailboxes.
• GALsync synchronizes between separate Exchange environments, including between two Microsoft 365 tenants, by exchanging a data file and creating mail-enabled contacts in the other directory.

contactSync cannot synchronize between two separate Microsoft 365 tenants. If the organizations being merged still have their own tenants, cross-tenant synchronization is GALsync's job, and no contactSync configuration will achieve it. This is worth establishing at the outset: the selective-scoping mechanics below are genuinely useful, but they only apply once the objects are reachable within one environment.

Practically, that means a post-acquisition scenario usually falls into one of two shapes:

1. The organizations already share a tenant, or the contacts have been brought into one — use contactSync, and scope with the methods below.
2. The organizations still have separate tenants — use GALsync between them, and scope the export policies. Deployment can be a single server or multiple servers; a hub-and-spoke arrangement is the usual pattern where more than two environments are involved.

Scoping who receives contacts in contactSync

The mailboxes that receive contacts are chosen on the policy's Mailboxes tab. Several selection methods are available, and they differ in how well they survive people joining and leaving.

By group — the recommended method. Search for and select a group, and contactSync resolves the members of that group that have mailboxes during the policy run. Membership is therefore always current without the policy being touched. In a hybrid environment, mailboxes can be selected from both Exchange on-premises and Exchange Online within the same policy, provided no Recipient Type has been selected on the Mailboxes tab.

By organizational unit. An OU selection offers several scopes, all resolved at run time: Only this OU, Only Sub-OUs, OU + Sub-OUs, Include group memberships (mailboxes that are members of a group located in a selected OU), and Include nested groups + memberships.

By dynamic distribution group. Useful where the recipient set is defined by an attribute — department, office, a custom attribute — rather than by an explicit list.

By Recipient Type — avoid. Where an existing policy selects a Recipient Type on the Mailboxes tab, NETsec recommends migrating that selection to a dynamic distribution group. Recipient Type selection also prevents mixing on-premises and Exchange Online mailboxes in one policy.

Two exclusion marks, and they are not the same

contactSync provides two custom-attribute marks. They are easy to confuse and they do opposite jobs. Both go in any custom attribute — extensionAttribute1 to extensionAttribute15 on-premises, or customAttribute1 to customAttribute15 in Exchange Online.

• NoMailboxSync stops a mailbox from receiving contacts. contactSync will not add that mailbox to the list of mailboxes that get directory objects, public folder contacts or shared mailbox contacts into their contact folder.
• NoContactSync stops an object from being synchronized as a contact — it excludes the object from the source set rather than excluding a recipient.

Choose by asking which side you are excluding: a person who should not receive the shared contacts takes NoMailboxSync; a person who should not appear in other people's contacts takes NoContactSync.

Building a bidirectional selective configuration

Direction is handled by having one policy per direction. There is no single two-way policy.

1. Create one recipient group per direction and give them names that state what they do, so the intent survives the person who set it up. For two organizations A and B, something like GG-B-Receives-A-Contacts and GG-A-Receives-B-Contacts.
2. Populate each group with only the people approved to receive the other organization's contacts.
3. Create the first policy: choose organization A's contacts as the source, and select the group of B recipients on the Mailboxes tab.
4. Create the second policy: choose organization B's contacts as the source, and select the group of A recipients.
5. Give each policy its own dedicated contact folder. This separates synchronized contacts from users' personal contacts, and — more importantly — stops two policies reconciling the same folder, which causes each to delete what the other created.
6. Pilot before expanding. Run each policy against a small number of real accounts and confirm the result before adding the full membership.

After that, adding or removing a person is a group membership change. No policy needs editing again, which is the main reason to prefer group-based targeting over direct selection.

References

• contactSync 8.7 Manual p.113 — the Mailboxes tab; group selection resolved at run time; hybrid selection; the NoMailboxSync mark.
• contactSync 8.7 Manual p.115 — OU selection scopes, including group memberships and nested groups.
• contactSync 8.7 Manual p.61 — the NoContactSync mark.
• The current contactSync and GALsync manuals are published by NETsec at netsec.de.