Handling Terminated Users and Alias Transfers in GALsync

Purpose

A user leaves. Their mailbox is removed in the source environment and their address is transferred to a manager or successor. The contact in the partner environment then neither updates nor disappears — it sits there, stale, and subordinates who reported to the departed person do not get their manager field updated either. This article explains why the ordering matters and gives the documented sequence that avoids it.

Why the contact gets stuck

GALsync matches synchronized objects by primary SMTP address. A termination workflow that transfers the departing user's address to someone else breaks that match in a particularly awkward way: the address GALsync used to identify the contact now belongs to a different object.

The result is that the contact is neither matched (the address is no longer on the original object) nor cleanly removed (the address still exists somewhere in the source). It stays until the address is removed entirely from the source environment.

The underlying mechanism is the same one behind several other GALsync behaviours — see How GALsync Matches Contacts, and What Happens When the Match Breaks.

The documented sequence

Order matters more than any individual step. Removing the mailbox first is what creates the stuck contact; removing it last avoids the problem.

1. Exclude the terminated user's mailbox from GALsync using the nogalsync mark in a custom attribute — extensionAttribute1 to extensionAttribute15 on-premises, or customAttribute1 to customAttribute15 in Exchange Online.
2. Set the manager's primary SMTP address as the target address on the departing user's mailbox. This forwards incoming mail to the manager while the mailbox still exists.
3. Wait for the GALsync synchronization cycle to complete. Do not proceed until it has.
4. Confirm the contact for the terminated mailbox has been removed in the target environment. GALsync removes it because the object is now out of scope.
5. Optionally add the departed user's primary SMTP address as a secondary address on the manager's mailbox, so mail sent to the old address continues to reach the right person.
6. Remove the terminated mailbox from Exchange.

The essential point is steps 3 and 4: the synchronization must run and the contact must be confirmed gone before the mailbox is deleted. Deleting the mailbox first removes GALsync's ability to reconcile the object at all.

# Step 1 - exclude from GALsync (Exchange Online)
Set-Mailbox -Identity <departing-user> -CustomAttribute1 'nogalsync'

# Step 2 - forward to the manager
Set-Mailbox -Identity <departing-user> -ForwardingSmtpAddress <manager-address>

# Step 5 - add the old address to the manager as a secondary
Set-Mailbox -Identity <manager> -EmailAddresses @{ add = 'smtp:<old-address>' }

Verify each step before moving to the next rather than scripting the whole sequence, because the waiting period in step 3 is what makes it work.

Manager fields on the remaining staff

Subordinates' manager attributes are a separate matter. GALsync exports the manager object when Synchronize Manager is enabled on the export policy — and it exports that manager even if the manager object is not itself within the export scope. On the import side, the corresponding option on the Directory Settings General tab sets the manager property on imported contacts and mail-users.

If subordinates' manager fields are not updating in the partner environment, confirm that option is enabled on both sides before investigating further. If the departed person is still showing as manager, the source directory itself may not have been updated — GALsync reflects the source, it does not infer a successor.

When a contact fails to update with an object-not-found error

Where the import log shows an error of this shape, the target object GALsync is trying to act on no longer exists as it expects:

The operation couldn't be performed because object '<guid>' couldn't be found on '<server>'

Before treating this as a defect, confirm two things: that the account running the Exchange Online session holds the permissions it needs, and that the ExchangeOnlineManagement PowerShell module is at the version the installed GALsync release requires. Both produce errors that look like missing objects rather than access failures.

Duplicate address-book entries in hybrid and multi-tenant setups

Where a person exists in two tenants — as a directory-synchronized user object in one and a GALsync-created contact in the other — both can appear in the address list, showing different sets of direct reports depending on which object is viewed.

This is a scoping problem rather than a defect. The object that should not be synchronized needs to leave the export's scope, using the nogalsync mark or an Object Filter condition on the export policy. See Controlling Which Objects GALsync and contactSync Synchronize.

Filtering on a tenant-specific domain suffix is a reasonable approach where the duplicate can be identified that way, but test it against a small policy first — an Object Filter excludes an object if any condition matches, and an over-broad condition removes more than intended.

References

• GALsync 8.7 Manual p.167 — Synchronize Manager on export and import policies; manager objects exported even when outside the export scope.
• GALsync 8.7 Manual p.173 — Export Settings: Object Filter and the default nogalsync rules.
• GALsync 8.7 Manual p.231 — the primary SMTP address as GALsync's matching criterion.
• The current GALsync manual is published by NETsec at netsec.de.