GALsync Imported Contacts Show a Hex Suffix or the Wrong Display Name

Purpose

Imported contacts appear in the address list with a long hexadecimal string appended to the name — for example Surname, Forename25f9604a… — while other contacts from the same policy import correctly. Alternatively the names import cleanly but in the wrong syntax for your environment. Both are addressed by controlling how the display name is built during import.

Where the hex suffix comes from

GALsync appends a unique suffix to a contact's internal name (Name / cn) to avoid naming collisions in Active Directory. That is deliberate. The problem is when the suffix becomes visible in the display name that users see in the address book.

Do not assume re-running the policy will clear it. The suffix is often removed on a subsequent run, but this is not reliable, and there are cases where a policy ran repeatedly over several days without the affected names correcting themselves. If you are waiting for it to resolve on its own, you may be waiting indefinitely.

The durable fix is to build the display name explicitly with property-modification rules on the import policy, so that whatever GALsync does to the internal cn, the visible displayName is constructed from the attributes you choose.

Building displayName with property rules

NETsec documents this as a three-rule pattern. The pipe character | is used as a separator within the rules, so it must not appear in the values of the attributes involved.

Rule 1 — Build property. Select displayName as the property to modify and choose the Build property option. The value differs by source environment:

# Exchange on-premises source
%sn%, %givenName%|%displayName%

# Exchange Online source
%LastName%, %FirstName%|%DisplayName%

The value after the pipe is the fallback. Not every object has a first and last name — room and equipment mailboxes typically do not — so the existing display name is used for those.

Rules 2 and 3 — tidy up the result. These remove the artefacts left when one of the name parts is empty:

^, \|

\|.*$

The first removes a leading comma and space where the surname was absent; the second removes the separator and everything after it once the built value has been resolved.

Restrict the build rule to source objects of type User or Contact, so that objects without name attributes fall through to their existing display name rather than being rebuilt into something empty.

A step that may not exist in your configuration

Guidance for this problem sometimes points at a Build the cn of the distinguishedName option in the import policy's Directory settings, with displayName as the source. Be aware that this option is not present in every configuration — it is absent in at least some Exchange Online environments using Graph, including GCC High deployments on a single server.

If you cannot find that option, you have not missed it. Use the property-modification rules above instead; they achieve the same outcome and do not depend on that setting being available.

Verifying the result

After the rules are in place, run the import and check the log for the contact creation calls. A correctly built name appears without the hex suffix:

New-MailContact -Name "Surname, Forename [SUFFIX]"

Then confirm in the target environment:

Connect-ExchangeOnline

Get-MailContact "<surname>" | Select-Object Name, DisplayName | Format-Table -AutoSize

# refresh the address list so the change is visible to clients
Update-AddressList -Identity "Default Global Address List"

Contacts already created with a malformed name are not renamed retrospectively by the rule change. They are corrected on their next update, or by removing them and letting the policy recreate them — but see the caution below before deleting anything.

Before deleting affected contacts

Deleting contacts to force a clean recreate is tempting when the address list looks wrong, and it does work. Two consequences are worth accepting deliberately rather than discovering afterwards:

• Recreated contacts get a new legacyExchangeDN, so cached Outlook entries pointing at the old objects will produce non-delivery reports until the cache refreshes. See How GALsync Matches Contacts, and What Happens When the Match Breaks.
• If the next export is incomplete for any reason, the contacts will not come back on schedule. Confirm the export is healthy before deleting anything in the target.

If imports are slow or collide with directory synchronization

Where an import competes with Entra Connect activity in the same window, consider scheduling it at a quieter time. This does not fix a malformed display name, but it reduces the collisions that cause GALsync to add the disambiguating suffix in the first place.

References

• GALsync 8.7 Manual p.212–213 — How to build the displayName attribute during the import; the Build property rule, the pipe separator convention, the fallback for objects without first and last names, and restricting the rule to User and Contact source objects.
• The current GALsync manual is published by NETsec at netsec.de.