Server configuration

Halo Link works best when installed on the same server as the PMS database. Installing Halo Link on any other server adds maintenance complexity, which is detailed below. Additionally, when making any changes to the configuration of a server that Halo Link is installed on or connected to, certain considerations need to be made. The following details how Halo Link handles such situations, and what needs to be considered for your server configuration.

Jump to...

Definitions Managing multiple Halo Links Multi-server setups Server changes quick guide

Contact us when...

You're migrating or restoring a server, as we may need to reconfigure the instance of Halo Link associated with your PMS ID. Otherwise, integrations may query the wrong server or not be able to query your practice at all.
- For security reasons, this process requires manual intervention by Halo after the server changes are complete.
- To decrease downtime, feel free to contact us ahead of time so we can be ready to restore services as quickly as possible.
PMS data isn't updating correctly or integrations are showing incorrect data. While this could be because of the integration, if you have recently changed something with the server or all integrations are affected, this may be due to an issue with Halo Link.
If you have any questions or concerns. We're happy to discuss your server setup in order to identify what you might need to watch out for, or how to include Halo Connect in your current processes.

Contact us

Definitions

Term	Definition	More info
Primary server	The server on which a PMS database is installed and which the PMS client software connects to.	Link
Secondary server(s)	Any other servers used by the practice which are not a primary server.	Link
Authoritative Halo Link instance	The singular Halo Link instance integrations are allowed to connect to.	Link
Non-authoritative Halo Link instance(s)	Any other Halo Link instances integrations are not allowed to connect to.	Link
Halo Cloud	Halo Connect's collection of API products.	Link
Halo Link	Halo Connect's local agent which connects to PMS databases to enable communication with Halo Cloud.	Link
Halo GUID	A unique identifier for each PMS database a Halo Link instance is connected to.	Link
PMS ID	A unique identifier assigned by PMS software that represents a practice in some way.

Managing multiple Halo Link instances: authoritative vs non-authoritative

Each Halo Link instance is given its own unique identifier -- what we call a Halo GUID. We associate Halo GUIDs with PMS IDs, which identify PMS licenses, in order to detect when one practice is running multiple installations of Halo Link which are connected to different copies of the PMS database. This usually happens if:

The practice has multiple servers which have the PMS database installed. This is usually due to backup systems creating duplicates of the practice's server.
The practice is migrating servers and needs to temporarily run two servers to ensure uptime during the switch.

This results in a situation where multiple Halo Link instances with different Halo GUIDs are connected to PMS databases which have the same PMS ID. For example:

graph TB
    subgraph Practice servers
        direction BT
        subgraph Primary server
            direction BT
            Zedmed1["PMS Database (PMS ID 1234)"]
            HL1["Halo Link (Halo GUID abcd)"]
            HL1 --> Zedmed1
        end
        subgraph Secondary server
            direction BT
            Zedmed2["PMS Database (PMS ID 1234)"]
            HL2["Halo Link (Halo GUID wxyz)"]
            HL2 --> Zedmed2
        end
    end

In both cases, we restrict integration access for that practice to only one Halo Link instance, and therefore to only one PMS database. We use the following terminology to differentiate the Halo Link instances:

The authoritative Halo Link instance is the Halo Link instance connected to the PMS database which integrations should be connecting to.
Non-authoritative Halo Link instances are any Halo Link instances installed on other servers which integrations should not be able to connect to. These can include backup, testing, and migration servers.

Which Halo Link instance should be authoritative?

Integrations should only be connecting to the PMS database which the PMS client that practice staff use is connected to. The authoritative Halo Link instance should be the one connected to that PMS database.

graph LR
    HC[Halo Cloud APIs]

    I1[PMS integration] --> HC
    I2[PMS integration] --> HC
    I3[PMS integration] --> HC

    subgraph Practice servers
        subgraph Primary server
            BP1[PMS database]
            HL1["Halo Link (authoritative)"]
            HL1 --> BP1
        end
        subgraph Secondary backup server
            direction LR
            BP2[PMS database]
            HL2["Halo Link (non-authoritative)"]
            HL2 --> BP2
        end
    end

    HC --> HL1

    subgraph Practice computers
        subgraph Staff computer
            BP1 --> C1[PMS Client]
        end
        subgraph Staff computer
            BP1 --> C2[PMS Client]
        end
        subgraph Staff computer
            BP1 --> C3[PMS Client]
        end
    end

Setting the authoritative Halo Link instance correctly is important to avoid:

Data degradation and desynchronisation due to some integrator queries going to one database and other queries going to the other database, resulting in the data in the two databases becoming different.
Backup corruption where a backup is meant to be a snapshot of the PMS database at a specific time, but integrator queries have caused changes since that time.
Incorrect data in the PMS client and/or integrations where the PMS client and/or integrations are pulling data from one database, but the other database is the one receiving updates.

For integrators: Handling 403 Forbidden errors

If an integration tries to query a non-authoritative Halo Link instance, it will receive a 403 Forbidden error. If that Halo GUID worked previously, this is likely a sign the practice has done a server migration or similar and now has a new authoritative Halo Link instance, which has a different Halo GUID.

To avoid service interruptions, integrations can automatically handle 403 errors using a workflow such as the one outlined in the Halo Cloud overview.

Which server is authoritative?

Halo Link decides whether a server is authoritative or not at installation. This is noted in Halo Link's logs.

Generally, the first installation of Halo Link for a PMS ID will automatically be set as authoritative. Subsequent installations which try to connect to a PMS database with the same ID will automatically be set as non-authoritative, whether or not Halo Link is being installed on the same server or a different server.

For Bp Premier integrators in staging...

Halo Link uses the Bp Site ID to determine if multiple Halo Link installs belong to the same "practice". When using a developer license for Bp Premier, the Bp Site ID is always 0. Because we cannot differentiate sites by Bp Site ID, all Halo Link installations in staging connected to a developer copy of Bp Premier are treated as authoritative.

Changing which server is authoritative

When migrating or restoring a server, which Halo Link instance is authoritative will likely need to be changed. For more information on what kinds of server changes may require an authoritative change, see the Server configurations page.

For security reasons, changing the authoritative Halo Link instance for a given PMS ID is a manual process requiring human intervention. To change which server is considered authoritative for a site, please contact us and include:

The server name
The PMS ID
The Halo GUID for the Halo Link instance which you want to make authoritative

To minimise interruptions to service, feel free to contact us ahead of any relevant server changes so we can be ready to switch over your authoritative Halo Link instance as quickly as possible once the server changes are complete. Including the server name and PMS ID will also allow us to watch for a new Halo Link instance coming online, reducing some of the back and forth.

Contact us to change the authoritative Halo Link instance for your site

Multi-server setups

Primary vs secondary servers

When dealing with multi-server setups, we use the following definitions:

Primary server: The server on which a PMS database is installed and which the PMS client software that practice staff use connects to.
Secondary server(s): Any other servers used by the practice which are not a primary server. Some secondary servers may also have the PMS database installed, but are considered secondary because they are not connected to the PMS client software which practice staff use.

We recommend installing the authoritative Halo Link instance on the primary server, to make maintenance easier. However, Halo Link can be installed on a secondary server by installing Halo Link via the installation wizard or command line and specifying the appropriate database hostname.

If you do want to install Halo Link on a secondary server, there are a few things that should be considered:

Increased risk of service disruptions due to connectivity issues. Any connection issues between the two servers will result in a service disruption for Halo Link, and therefore any integrations which connect to the PMS database via Halo Cloud.
Changes to the primary server may require updates to the secondary server. For example, if the primary server is migrated and the database hostname changes, the database hostname Halo Link is looking for will also have to be updated.
Installing or updating the PMS database may install Halo Link on the primary server. If this happens, the new Halo Link install on the primary server should be set as non-authoritative and therefore should not impact integrations, however it still means there is an extra program on the primary server which is connected to the internet, receives updates, and sends heartbeats back to Halo Cloud every minute.
- Note: Some PMS software may be able to detect an existing instance of Halo Link. This will depend on the PMS and what checks their installer does.

Running multiple servers

Some practices run multiple servers permanently. To ensure Halo Link is running correctly and there are no service disruptions to the practice, please:

Authoritative vs non-authoritative: As above, you will need to ensure the authoritative Halo Link instance is correctly set. Whenever you make changes to either server which may affect the registry or cause Halo Link to be re-installed, cloned, or otherwise affected, please check that server's authoritative status in Halo Link's logs.
Multiple Halo GUIDs: Integrators use the Halo GUID assigned to the authoritative Halo Link instance to route queries to the correct practice. Each Halo Link instance has its own Halo GUID, including any non-authoritative Halo Link instances. So when sharing the Halo GUID with an integrator or with Halo Support, please ensure it is the Halo GUID for the correct Halo Link instance.

When running multiple servers permanently, we recommend uninstalling or disabling any non-authoritative Halo Link instances first. However, please note:

If you uninstall Halo Link, it may be reinstalled when cloning the primary server or when installing or updating the PMS software. For example, Halo Link is bundled with most Bp Premier data updates and service packs.
If you disable the Halo Link service, it may restart itself when we release an update. Therefore, please also disable the Halo Link Updater scheduled task to prevent this.

Server changes

When upgrading, migrating, cloning, restoring, or otherwise changing the practice servers, there is a chance that Halo Link may be impacted. The following details when this can happen and what can be done about it.

Quick guide

Change	Action required	More info
Server OS upgrade	No action required.	Link
Server migration	Install Halo Link on the new server, uninstall from old server, and send Halo Connect the new server's Halo GUID.	Link
Server clones and restoration	Uninstall unwanted Halo Link copies and restart wanted copies.	Link

General guidance

As a general rule, Halo Link should not be impacted by server changes if:

Halo Link's registry values have not changed. The Halo Link installer will honour any existing registry values, so even if Halo Link must be reinstalled, as long the registry has not changed, then Halo Link will reconnect using its previous settings.
Each Halo Link instance has a unique Halo GUID. Since Halo GUIDs are used for routing queries from integrations, if two Halo Link instances have the same Halo GUID this can cause unpredictable behaviour. This is usually caused by backups or server clones which copy the Halo Link registry values and have Halo Link installed and running.

To check if Halo Link has been affected by server changes, we recommend:

Before:
- Note the Halo GUID(s) found in the Halo Link logs or registry for later for each instance of Halo Link which may be affected.
After:
- Check Halo Link's registry values exist.
- If modifying one server, check the Halo GUID is the same as before and that its logs state it is authoritative.
- If modifying multiple servers with Halo Link installed, check each has a unique Halo GUID. If the authoritative Halo Link instance should not have changed, check its Halo GUID is the same as before and that its logs state it is authoritative.
- Check the Halo Link Service is running and the Halo Link Updater service is present and set to manual, as per the screenshot below.
- Check the Halo Link scheduled updater task is running.

Halo Link's registry values can be found at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Halo Connect\Halo Link and instructions for finding Halo Link's application logs are here.

Server OS upgrades

Upgrading a server's operating system is unlikely to cause issues with Halo Link, as it rarely affects the registry.

If you have any concerns or experience any issues with integrations please contact Halo Connect Support for further assistance.

Server migrations

If a full server migration has taken place, you will need to work through the following migration guide in order to allow integrators to connect, and extract from the new server.

Step 1: Check the new server

Because Halo Link is bundled with some PMS software, Halo link may already be installed on your new server.

Navigate to the services application on your Windows server.
To verify that Halo Link is installed, scroll down and locate "Halo Link Service" and "Halo Link Updater".
If Halo Link is not installed, work through the system requirements and installation guide, then check again. If Halo Link is still not installed, please contact Halo Connect Support for further assistance.

graph LR
    id1{"Check if 
    Halo Link is installed 
    on the new server"}
    id2[Review Halo Link requirements]
    id3[Install Halo Link]
    id4{Installed correctly?}
    id5[Contact Halo Support]    
    id1--No -->id2-->id3-->id4
    id4--No -->id5
    id6[Go to Step 2]
    id1--Yes-->id6
    id4--Yes-->id6

Step 2: Finalise migration

Uninstall Halo Link from the old server.
Retrieve the Halo GUID of the Halo Link installation on the new server.
Contact Halo Connect Support and share the retrieved Halo GUID. This allows our team to change which instance of Halo Link associated with this PMS (Practice Management Software) ID is set as authoritative, and able to be queried by integrators.

graph LR
    id6[Uninstall Halo Link from the old server]
    id7[Retrieve the Halo GUID of the new server]
    id8[Send Halo Support the new server's Halo GUID]
    id6-->id7-->id8

Restoration or cloning

When a server is restored from a backup or the server is cloned, it will clone the pre-existing instance of Halo Link, creating two instances of Halo Link with the same Halo GUID. This causes a conflict between the two instances associated with the practice, which requires manual intervention by the practice to fix.

Clone server to a different VM

If the server has been cloned on a different virtual machine, the unwanted copy of Halo Link will need to be uninstalled. Once it is uninstalled, the wanted copy should be restarted to open a new session and reset its connection to Halo Cloud.
Restore to same server

If the server has been restored from a backup on the same server, the Halo link service will need to be stopped, then restarted. This will reset its connection to Halo Cloud.

Prev: Updating Halo Link