How to Export Microsoft 365 Contacts to On-Premises Active Directory Using GALsync

Purpose

You want a copy of mail-enabled objects that live in a Microsoft 365 tenant to exist as contacts in an on-premises Active Directory. GALsync does this, but not in the way people usually expect, and there is one constraint that determines whether the design is safe at all. This article covers both.

The architecture: two instances, not one

A GALsync instance running in cloud-only mode cannot write to an on-premises Active Directory. It can export from Exchange Online, but it has no path into the local directory. This is the single most common misunderstanding about this scenario.

The complete flow needs two GALsync instances:

1. An export policy, on the instance configured for the Exchange Online environment, which selects the objects and writes a data file.
2. The data file is transferred to the other side.
3. An import policy, on an on-premises GALsync instance, which reads the data file and creates mail-enabled contacts in a target organizational unit.

A policy defines what data is shared, the method used to transfer it, the target, the address for the administrative report, and the schedule on which it runs. The transfer method can be mail, FTP or a network share, with encryption — so the two instances do not need direct network access to one another.

The constraint that decides whether this is safe

Before building anything, establish where the objects you want to copy actually originate.

This design is only safe for objects that exist solely in the tenant. If an object is already being synchronized from on-premises Active Directory up to Microsoft 365 — by Entra Connect, formerly Azure AD Connect — then importing it back down creates a conflict between GALsync's contact and the directory-synchronized object representing the same person.

Import into an organizational unit that is not synchronized to the tenant. If the target OU is in Entra Connect's scope, the contacts GALsync creates will be synchronized up into the tenant, where they will collide with the objects they were copied from. Excluding the target OU from directory synchronization is what keeps the two directions separate.

The symptom when this goes wrong is distinctive. The GALsync import log records an Exmessage beginning:

An Azure Active Directory call was made to keep object sync between Azure Active
Directory and Exchange Online. However, it failed.

That entry means a specific user or contact being synchronized from Entra ID is conflicting with a contact GALsync is trying to import. The log entry identifies the objects involved by object ID, and NETsec's documented next step is to look them up and establish whether they can be removed:

Connect-AzureAD

Get-AzureADObjectByObjectId -ObjectId <object-id-from-the-log>

Disconnect-AzureAD

If you find yourself doing this routinely, the OU scoping is wrong rather than the individual objects.

Building the export policy

1. On the instance connected to the Exchange Online environment, create an export policy.
2. Select the objects to export. They can be chosen by search, by group membership, or by dynamic distribution group. Dynamic distribution groups are the more robust choice for an ongoing synchronization, because membership is evaluated at run time and does not need maintaining as people join and leave.
3. Set the transfer method — mail, FTP or network share — and enable encryption.
4. Set the safety limits on the export policy's Directory Settings: Minimum objects to transfer data file and Maximum errors to transfer data file. These stop an incomplete export from reaching the import, which would otherwise delete contacts that still exist at the source. See How to Prevent GALsync Contact Deletion During Export Errors.
5. Consider Export 'MasteredOnPremise' objects, an Exchange Online export option covering objects that are mastered on-premises and synchronized up by Entra Connect. In this scenario you generally want it off, since those objects already exist on-premises and are precisely the ones that must not be copied back.

Building the import policy

1. On the on-premises instance, create an import policy that reads the transferred data file.
2. Choose the target organizational unit, confirming it is excluded from directory synchronization.
3. Give the GALsync service account write permissions to that OU. Import failures that look like data problems are frequently permissions on the target container.
4. Use one import policy per organizational unit. Where two import policies write into the same OU, each will delete objects created by the other, because each treats the OU's contents as its own to reconcile.

Verifying the result

1. Run the export and confirm the data file was produced and transferred.
2. Run the import and check the object count created against the count exported.
3. Confirm the contacts appear in the target OU as mail-enabled contacts with their addresses intact.
4. Confirm the OU is not appearing in Entra Connect's synchronization scope — ideally by checking the connector configuration rather than by waiting to see whether objects appear in the tenant.
5. Check the match counters in the import log summary. See How GALsync Matches Contacts, and What Happens When the Match Breaks.

References

• GALsync 8.7 Manual p.74 — policy components; transfer by mail, FTP or network share with encryption; file and configuration locations.
• GALsync 8.7 Manual p.167 — Export 'MasteredOnPremise' objects; the export safety limits.
• GALsync 8.7 Manual p.308 — the Entra ID object-sync conflict message and how to identify the conflicting objects.
• GALsync 8.7 Manual p.12 — one import policy per organizational unit.
• The current GALsync manual is published by NETsec at netsec.de.