Moving a GALsync Installation to a New Server or Azure VM

Purpose

Moving GALsync to a new server — often an Azure VM as part of leaving on-premises infrastructure — is a well-trodden path, but the published short version leaves out the step that takes the longest. This article gives the full sequence.

The step people are not expecting

A server move is usually also an authentication migration. If the existing installation uses user-based authentication for Exchange Online, that will not carry forward: user-based authentication has been removed, and certificate-based authentication through an Entra ID App Registration is the only supported method.

So the work is not "install, import config, done." Budget for the App Registration, and arrange for a Global Administrator to be available when you do it, because consent has to be granted in the tenant.

Plan this before the move rather than discovering it mid-migration.

Preparing the new server

Build the VM on a supported Windows Server version and apply updates.
Join it to the domain if the synchronization involves on-premises Active Directory.
Install the ExchangeOnlineManagement PowerShell module, then reboot. The reboot matters — GALsync may not recognise a freshly installed module until the server restarts.
```
Install-Module ExchangeOnlineManagement -Force -Scope AllUsers
```
Confirm .NET Framework 4.8 or later and Windows PowerShell 5.1.
Confirm outbound connectivity to Microsoft 365, and to whatever transfer method your policies use — mail, FTP or a network share.
Verify the service account can sign in to the new server and holds local administrator rights on it. Domain Admin is not required; local admin on the GALsync server plus delegated permissions on the target OU is the appropriate level.
Install GALsync while logged on as the service account. This matters for the same reason it matters later — certificates and modules land in the profile of the account that creates them, and the service runs as that account.

Migrating the configuration

On the old server, before decommissioning it:

Action → Export Configuration — zips the policies and environment configuration.
Action → Export Status — zips the log files. Keep these; they are your record of what the object counts looked like before the move.

On the new server:

Apply the licence — Help → About → Add License. If the move also involves a version change, make sure the key matches the version you are installing. See GALsync Licensing: Delivery, Activation, Renewal and Upgrades.
Import the configuration — Action → Import Configuration, and select the zip exported from the old server.
Switch to certificate-based authentication. Create the certificate from within GALsync while logged on as the service account, upload the public certificate to the App Registration in Entra ID, assign the API permissions and the Exchange role, and grant admin consent.
Clear stale data files from the GALsync mailbox. Delete old import email, leaving only the most recent data file for each import policy. Skipping this can cause an old data file to be imported, which — because the import reconciles against what it receives — can delete contacts that still exist at the source.
Test the connection from within GALsync before enabling any schedule.
Run one policy manually and compare the object count against the figure from the old server's logs.
Re-enable the schedules. Policies resume on their previously configured schedule once the configuration is imported.

Verify before you decommission

Keep the old server available, with its schedules disabled, until you have confirmed:

A full export and import cycle completes with object counts matching the old server.
A scheduled run works, not only a manual one — scheduled policies run as the service account, and this is where a certificate or module installed under the wrong profile shows up.
Your synchronization partners are seeing current data. A partner-side problem after a migration is easy to miss from your side, since your own logs look clean.

That last point is worth taking seriously. Check with the other side rather than assuming silence means success.

Both sides must not run at once

Make sure only one installation is running policies. Two servers running the same import policies against the same target will each reconcile the target against their own data file and delete each other's contacts. Disable schedules on the old server before enabling them on the new one.

After the move

Re-check two things that are easy to lose in a migration:

Antivirus exclusions on the new server, for both the program folder and the data folder under %ProgramData%. See Antivirus Exclusions for the GALsync and contactSync Server.
Export safety limits — Minimum objects to transfer data file and Maximum errors to transfer data file — which protect you against exactly the kind of anomaly a migration can produce.

References

GALsync 8.7 Manual — How to switch from user-based authentication to certificate-based authentication.
GALsync 8.7 Upgrade Instructions p.10 — platform prerequisites; removal of user-based authentication.
GALsync 8.7 Manual p.74 — program and data folder locations.
The current GALsync manual and upgrade instructions are published by NETsec at netsec.de.

Articles in this section