Add2Exchange Enterprise
GAL Sync vs. Regular Contact Sync 

Technical Sales Overview, Structure Guide, and Deployment Summary

Document Version	4.2	Document Date	April 1, 2026
Audience	Prospective and evaluating GAL Sync clients	Applies To	On-prem Exchange, Hybrid, and Microsoft 365
Deployment Models	DidItBetter Hosted or Customer Hosted	Schema Changes	None required
Positioning	Straightforward deployment, low-touch administration, and simple onboarding/offboarding through group membership	Mobile Outcome	Corporate contacts available through normal mailbox contact experiences for Outlook, caller ID, text recognition, and native phone contact visibility

 

Add2Exchange Enterprise provides server-based synchronization for both official company directory publishing and regular shared contact synchronization. For GAL Sync, the platform automatically publishes selected directory objects into normal mailbox Contacts folders so users get a usable corporate address book in Outlook and on supported mobile experiences. That supports practical outcomes such as caller ID recognition, text message identification, and optional photo-aware contact visibility when that data is available. Once the service account, permissions, and lists are in place, routine administration becomes largely a group-membership task instead of a mailbox-by-mailbox project.

 

1. Why this is easy to deploy and maintain

• No software is required on individual workstations or mobile devices.
• No schema changes are required in Active Directory or Exchange.
• The synchronization engine is centrally managed from one replication server, whether hosted by DidItBetter or placed inside the customer environment.
• Template-based relationships reduce the need to build and maintain one-off per-user sync configurations.
• Onboarding and offboarding are primarily driven by adding or removing users or objects from the appropriate distribution groups.
• Incremental updates keep routine synchronization efficient after the initial population.
• GAL inclusions and exclusions allow customers to publish the right corporate contacts while omitting service accounts or other unwanted objects.
  Single-point installation and central administration keep deployment efficient because nothing is installed on each desktop or phone.
  DidItBetter guided implementation and template-based relationship design shorten the proof-of-concept and rollout process.

2. GAL Sync vs. Regular Contact Sync

Category	GAL Sync	Regular Contact Sync
Primary source	Objects selected from the Global Address List by membership in zgalinclude.	A specific Contacts folder such as a mailbox, shared mailbox, public folder, or resource mailbox.
Working folder	Requires a GALCache folder to stage generated GAL contacts before publication.	No cache folder is required; the source Contacts folder is synchronized directly.
Recipients	Users who should receive the corporate directory are placed in zgalsync.	Users who should receive the shared contacts are placed in a destination list such as zcontactssync.
Best use	Publishing an official company directory or a curated subset of the directory.	Publishing clients, vendors, departmental contacts, project contacts, or other non-GAL data.
Administration style	Directory-driven and template-friendly, which makes adds, changes, and removals predictable.	Source-folder driven, which is ideal when a team maintains the shared records directly.
User result	Users receive company contacts that can support caller ID recognition, text identification, and photo display when that data is available.	Users receive the shared contacts they need without mixing them into the official company directory pipeline.

 

3. Moving parts and what each one does

Component	Purpose	Used In
zgalinclude	Defines which unhidden GAL objects should be turned into contact records for publication, including mailboxes, contacts, distribution lists, resources, and email-enabled folders.	GAL Sync
GALCache	Stores the working copy of the generated GAL contacts before delivery to users. This is the staging area unique to GAL Sync.	GAL Sync
zgalsync	Defines which destination users receive the published GAL contacts.	GAL Sync
Source Contacts folder	Holds the contacts to be shared, such as clients, vendors, or departmental contacts.	Regular Contact Sync
Destination sync list	Defines which users receive the shared non-GAL contact set; common examples include lists such as zcontactssync.	Regular Contact Sync
Relationship Group Manager	Watches membership changes and updates template-driven relationships automatically on the scheduled interval.	Both

4. Structure and synchronization flow

GAL Sync flow

Flow: zgalinclude  ->  GALCache  ->  zgalsync  ->  User Contacts folders

• zgalinclude holds the corporate objects you want published, such as mailboxes, contacts, distribution lists, resources, and email-enabled folders.
• Add2Exchange converts those selected GAL objects into contact records and stages them in the GALCache folder.
• The contents of GALCache are synchronized to every destination mailbox that belongs to zgalsync.
• Users can still keep their own personal contacts while also receiving the synchronized corporate directory.

Regular Contact Sync flow

Flow: Source Contacts folder  ->  Destination sync list  ->  User Contacts folders

• A source Contacts folder contains the records to be distributed, such as clients, vendors, or shared departmental contacts.
• A destination list such as zcontactssync identifies the users who should receive those records.
• No GALCache folder is required for this workflow because the contacts are synchronized directly from the source folder.
• This makes it easy to publish targeted, non-GAL contact sets without mixing them into the official company directory.

Note: The two pipelines can coexist. A user can receive the official company directory through zgalsync and also receive one or more targeted shared contact sets through regular contact synchronization.  Calendars and other types of sync are supported from the single Add2Exchange Enterprise Console as well.

5. Common GAL Sync uses

Use case	Why customers like it
Enterprise mobility	Employees can see company contacts on iPhones, Android devices, Outlook, and other supported mobile experiences because the contacts are written into normal mailbox Contacts folders.
Caller ID recognition	Corporate contacts can be recognized when an internal caller rings instead of appearing as an unknown number.
Text message identification	Coworkers and business contacts can be easier to recognize in texting workflows when the synchronized contact information is present on the device.
Photo display	If profile photos are available and included, users can see who is calling instead of only a number.
Cross-tenant collaboration	Useful when organizations need to publish a usable corporate address book across multiple domains, tenants, or environments during collaboration projects.
Mergers and acquisitions	Helpful when two different companies need temporary or staged directory visibility during transition, migration, or consolidation periods.

6. Key features that reduce deployment friction

• Automatic GAL synchronization from selected directory objects to selected destination users, using one-way source-to-destination templates for faster deployment.
• Support for inclusions and exclusions so the published corporate directory stays curated and service accounts or unwanted objects can be omitted.
• Single-point installation with centrally managed relationship templates for faster deployment, easier scaling, and lower ongoing administration.
• Support for distribution lists, contacts, resources, and email-enabled folders as published objects, including curated subsets of the GAL.
• Optional synchronization of Active Directory photos where the customer wants photo-aware caller recognition.
• Ability to sync to all users or only selected users, depending on the customer's access, visibility, and security goals.
• Conditional field selection lets customers decide which address-book fields are published, while advanced options can control display-name format.
• Advanced GAL options can control display-name formatting and allow customers to decide which fields are published to users.
• The same architecture is useful for on-prem Exchange, hybrid projects, Microsoft 365 deployments, and selected cross-organization directory-sharing scenarios.
  Does not require Exchange ActiveSync to sync the apps to the phone native contacts. The reason for not wanting an Exchange ActiveSync requirement is that customers do not want users reauthenticating every time their password expires.

7. Requirements and prerequisites

Deployment options

• DidItBetter Hosted: the synchronization engine runs on a secure hosted replication server for faster deployment and simplified maintenance.
• Customer Hosted: the synchronization engine runs on a dedicated customer system or cloud VM for organizations that prefer internal control.

Customer-hosted server guidelines

• Windows 11 through Windows Server 2025.
• Minimum 2 CPU cores, 8 GB RAM, and 200 GB disk.
• Dedicated or lightly loaded system with minimal unrelated software installed.
• Fully patched operating system and minimal restrictive policy conflicts.

Synchronization service account

• Use a dedicated service account with its own mailbox.
• Do not hide the service account from the GAL.
• Do not reuse the account for unrelated services.
• Use a name that fits the customer's convention; many organizations place a z-prefix on the account so it sorts low in the address list.

Permissions

Environment	Recommended permissions
On-prem Exchange	Domain User and Exchange Organization Administrator
Microsoft 365	Exchange Administrator

Required lists and folders

• GAL Sync requires zgalinclude, a GALCache folder, and zgalsync.
• Regular Contact Sync requires a source Contacts folder and a destination sync list such as zcontactssync.
• GALCache can be located in a public folder, the service account mailbox, a shared mailbox, or a resource mailbox.

Note: Mobile design requirement: does not require Exchange ActiveSync just to make GAL data available in native phone contacts. The goal is to reduce user disruption and avoid repeated reauthentication events when passwords expire.

8. Deployment workflow

Proof of concept: Start with a pilot to confirm permissions, destination behavior, and mobile visibility in the customer environment.

Prepare the service account and lists: Create the service account, assign permissions, and build the required distribution lists and folders.

Install and configure: Install Add2Exchange Enterprise, SQL Express, and required support components on the replication server.

Assign mailbox access: Apply the required PowerShell-based access and automation permissions for the service account.

Build the relationships: Configure the GAL Sync or regular contact sync relationships and confirm the correct destination folders.

Test with pilot users: Validate contact creation, updates, removals, Outlook behavior, and mobile results before broad rollout.

Move to production: Expand membership in the destination groups to onboard the remaining users.

9. Onboarding and offboarding

Administrative action	GAL Sync	Regular Contact Sync
Give a user the corporate directory	Add the user to zgalsync.	Not applicable.
Publish a new object in the company directory	Add the mailbox, contact, distribution list, resource, or email-enabled folder to zgalinclude.	Not applicable.
Stop publishing a GAL object	Remove the object from zgalinclude.	Not applicable.
Give a user a shared contact set	Optional if the user should receive both corporate and shared contacts.	Add the user to the destination sync list such as zcontactssync.
Stop sharing a non-GAL contact set	Not applicable.	Remove the user from the destination sync list.

 

Note: For most customers, onboarding and offboarding becomes a distribution-list administration task rather than a manual mailbox-by-mailbox contact publishing project.

10. Ongoing administration and maintenance

• Relationship Group Manager monitors group membership changes and updates template-driven relationships automatically on the scheduled interval, commonly every six hours by default.
• Monitoring can be performed through Add2Exchange Event Logs, console monitoring, and optional slow-sync alerting.
• GALCache is used only for GAL Sync; regular contact sync does not need a cache folder.
• Because the design is template based and group driven, long-term maintenance is generally low touch compared with per-user synchronization models.
• Administration remains centralized, so updates, exclusions, adjustments, and troubleshooting can be handled from one place.

11. When to recommend each approach

Recommendation	Best fit
Recommend GAL Sync	When the goal is to give users an official company directory or a curated subset of the directory, with automatic updates based on directory membership.
Recommend Regular Contact Sync	When the goal is to distribute specific shared contacts such as vendors, clients, outside counsel, departmental contacts, or project lists.
Recommend both	When users need the corporate directory as well as one or more targeted shared contact collections.

12. Summary

Add2Exchange Enterprise makes GAL synchronization and regular contact synchronization approachable because the design is clean and predictable. GAL Sync uses zgalinclude, GALCache, and zgalsync to publish directory-driven contacts for Outlook and supported mobile experiences, while regular contact sync uses a source Contacts folder and a destination list to publish non-GAL contacts. Both models avoid schema changes, minimize client-side complexity, support straightforward onboarding and offboarding through list membership, and give customers a centrally managed way to deliver company contacts for visibility, caller ID, and related contact-recognition use cases.